[iain]

It seems so far this issue is somehow tied to replication. Removing our OD replicas has prevented the issue from continuing. Specifically, the issue prevented SMB and MS-CHAPv2 authentication, while other auth mechs continued to function.

[iain]

Now the next question I have is, has anyone been able to assign specific OD groups on a per-nas basis in Radius? I’d love to hear from you.

I have successfully set up Juniper firewalls to authenticate off OD Radius, but I need to assign access to specific groups on specific appliances. I’m assuming this could be configured in clients.conf, but I don’t see a mechanism to assign a group per nas.

Thanks,

-Iain

[iain]

This issue was related to another MS-CHAPv2 auth issue I was having. It inexplicably seems to be tied to replication. I have removed all replicas from this master and everything seems to be fine. Another user had the same issue I did, authenticating with NTLMv2. Removing his replicas fixed the recurring issue.

Users who have this problem can be reliably identified by checking if the hash-only bit is set in mkpassdb for the guid of the user.

I have not received word back from Apple on this issue, but sent them the information.

[iain]

It appears that accounts with the hash-only bit set to 1 are the issue. When I do a mkpass -dump on the guid, any user that has problems with radius or ms-chapv2 has this set to 1. It seems like this would be an easy issue to solve, if it did not recur at random times.

Does anyone know what specifically controls this flag? It would be great to be able to fix this problem w/o having to issue a password change for the user each time, to at least make some headway.

[iain]

At first glance it looks like sm.xml could be edited to enable roster.xml, where a set of default groups could be outlined. However, I’m concerned I might mess with the OD-specific components of the iChat server.

[iain]

The quad core xserves that shipped with 10.4.x (10.5.?) had lights that represented each core’s activity, with 4 lights always lit up. When you upgrade the server to 10.5.x, the light behavior becomes like the original xserve’s. Perhaps this was what you were experiencing.

[iain]

I have not received a reply from Apple on this yet.

It’s unfortunate to hear this might be more widespread than simply an issue with the MS-CHAPv2 plug-in.

If you do file a bug report at radar.apple.com, you can reference my filed report id of 6112273 as additional ammunition.

Does resetting the user’s password in WGM fix the problem, even by re-typing the same password? Is this issue affecting all users authenticated through OD?

We ended up adding local records to the VPN server to deal with this problem, so they have a separate password for their VPN connections. Annoying, but workable for now.

Unfortunately the problem came up at seemingly random times, and was not reproducible. This made it very hard to provide a compelling argument to Apple. We really could not isolate anything in the logs, apart from that wrong-sized secret issue in system.log.

Good luck,

-Iain

[iain]

[quote]
openssl s_client -connect leo.gac.edu:5223
connect: Connection refused
connect:errno=61

After editing the file AND commenting out the CACHAIN line I received:
(part of cert removed for security)

openssl s_client -connect leo.gac.edu:5223
CONNECTED(00000003)
[/quote]

I can confirm that commenting out the CACHAIN line solves this problem on a stock install, using a Thawte wildcard cert installed via Server Admin.

-Iain

[iain]

Thanks for the response, I thought as much, unfortunately. We’ll have to consider the risks of this, assuming it would pass a PCI audit.

The primary motivator for considering this is an intermittent issue we’re experiencing with the MS-CHAPv2 plug-in (wrong-sized secret 32 error) on OD. Hopefully I’ll get some response, positive or negative, from Apple on that issue. Either there are few people using Server in that configuration, or I’m overlooking something.

Thanks again, great site.

-Iain

[iain]

Thanks for the response. I just have to say there are so many cool features tying into OD these days, I just wish there was better documentation. It seems that until X Server is officially documented at a lower level, these very exciting developments will remain on the fringe in business environments. It’s hard to put my weight behind technology choices when I don’t have the technical docs to rely on, and have to go scraping forums for advice. Yes, yes, just rtfm on freeradius. This is a good example of where the FreeRADIUS documentation is all there in their wiki, but much of it is not applicable to the X Server user and you have to wade through stuff just to get a baseline understanding. Another example would be the LDAP/SSL client changes. A good idea, but implemented in a beta-test style with no docs until the user community figures it out. I guess this is a fun challenge, but not when you’re trying to make money with the software at some point. 😀

Thanks, AFP548 has played a good hand in my troubleshooting.

Iain

[iain]

Hmm, now it seems to be working again, with essential zero changes made to the config. Ahhh, leopard.

I’d love a detailed account of the exchange between radius and open directory. I have no problem at all doing legwork in the configs, but I just need the docs to reference! FreeRADIUS docs are not a quick read, but somewhat helpful.

[iain]

Also, how could I get radiusd in debug mode, considering its executed via launchd? I tried adding the x flag to the launchdaemon plist file, but it gets overwritten. Sorry for my ignorance of the launchd process.

Thanks,

-Iain

[iain]

actually it looks like most of the necessary UDP and TCP ports are listed out in the firewall configuration section, not the index (or perhaps I missed it), for future reference.

thanks again,

Iain

[iain]

Thanks, can’t believe I missed it.

[Author]

Posts