Get and use secure supported LDAP SASL authentication mechanisms

You don’t have to use insecure clear text Simple BIND authentication for accessing your LDAP servers.

Get list of supported authentication mechanisms:

ldapsearch -h example.com -x -b "" -s base -LLL supportedSASLMechanisms

Kerberos GSSAPI Example:

kinit
ldapsearch -v -Y GSSAPI -h example.com -b "DC=example,DC=com" "(sAMAccountName=someusername)"

DIGEST-MD5 Example:

ldapsearch -v -Y DIGEST-MD5 -h example.com -U someusername -R example.com -b "DC=example,DC=com"\
 "(sAMAccountName=someusername)"
Note: For Active Directory Digest Authentication to work, you may need to enable Reversible encryption on the account’s password and change the user’s password once.

Set DirectoryService debug level

Apple’s document on Extending and Troubleshooting Directory Services has a lot of good info.

One correction though is that the debug level must be an integer.
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -integer 2

I’ve notified Apple, so this may be fixed by the time you read this.

Update: That link is dead. Here is an article that offers some similar information.


AD Plugin Join Replication Issues

I was getting random AD plugin connection issues after joining to Active Directory. dsconfigad showed no errors, but sometimes I would not get a connection and I would have to rejoin. The problem turned out to be related to replication.

The AD plugin initially has no knowledge of which AD site and domain controllers are considered local to your subnet, so it discovers any domain controllers and contacts one to lookup the site information. During this process, and in general, the AD Plugin keeps an LDAP connection open to the domain controller. The AD plugin likes to reuse these LDAP connections, presumably for performance reasons. When it is time to actually add the computer to the domain, the AD Plugin reuses this existing connection. The problem is that this domain controller is not necessarily one within your AD site.

At this point, if the Mac is restarted or DirectoryService is killed, any new connections will be made to a DC in the subnet’s AD site, but if your computer was added to a non-local DC, the local DCs may have no knowledge of your computer because the computer account has not yet replicated to them.

This problem can appear to be quite random because sometimes you’ll get lucky and get a local DC for the join, or you might catch the replication at the right time. You might also see bad password errors in the DirectoryService debug logs. I have filed a bug report on this, and I don’t have a good workaround for now other than — don’t reboot or restart DirectoryService after a join. Of course if you know your replication schedules, you could just wait until you are sure replication is completed.

This same issue can present itself with unjoins and rejoins.

You can see what domain controllers you are connecting to during the join using the following shell command assuming your are joining using dsconfigad:

while [ 1 ]; do if netstat -a | grep ldap| grep ESTAB; then ps auxww | grep dsconfigad | grep -v grep; date;fi; done

If you have joined, unjoined, and rejoined and think you may be seeing replication issues, compare the whenCreated attribute of the computer account on different domain controllers using ldapsearch.

ldapsearch -LLL -v -W -x -h domaincontrollerfromsite1.subdomain.forest.com -D username@subdomain.forest.com -b "OU=Computers,DC=subdomain,DC=forest,DC=com" CN=machine-join-name | grep whenCreated:

If an older out of sync computer account exists, its whenCreated date will be different from the domain controller the computer was just added to until the last join has replicated to all the servers.


Fix for slow AD logins/joins caused by macAddress query

I’ve been hassling Apple about this issue for quite a while.

Apple has two workarounds for this problem:

1.) Index the macAddress attribute in AD. Even though the macAddress is not part of the Computer class by default, the AD plugin queries on it for joins ( to ensure the the computer that you are adding doesn’t already exist ), and for MCX ( managed client information ). Normally I would frown on any changes to AD since the Enterprise doesn’t like making changes to their infrastructure just to support Macs. However, supposedly in Windows 2008 Server, the macAddress attribute is indexed by default, so at least their is some justification there.

2.) If you’d prefer to make changes on your client machines rather than bother your AD administrators with a Mac-specific fix, remove the ENetAddress mapping from /Library/Preferences/ActiveDirectory.plist. The lines to remove look like this:

<key>1.3.6.1.1.1.1.22</key>
<string>dsAttrTypeStandard:ENetAddress</string>

The key is the OID for the macAddress attribute in AD.
The string value is the mapping to a native Open Directory attribute, which Apple calls ENetAddress.

Update:
You’ll also need to remove /Library/Preferences/DirectoryService/ActiveDirectoryDynamicData.plist as this file also contains the cached mappings.

Then killall -9 DirectoryService or reboot the machine.


Notes on Leopard AD Plugin 10.5.3

All of the bugs listed here are fixed in 10.5.3.

What isn’t fixed is the slow logins on AD environments with an R2 schema that hasn’t been extended with Mac attributes.

Again, please file bug reports if you are experiencing this issue.


Follow

Get every new post delivered to your Inbox.

Join 30 other followers