My Blog: IT & T in Australia

This year I’ve been working on integrating our 100 iMac and Macbooks into our existing Windows network. In the past, we had an Xserve running OS X Server 10.6 that served as an Open Directory master and an AFP file server. Accounts were added to Open Directory on a request basis – if a student needed to use the Macs, they had to request an account. We’ve now integrated the Macs into Active Directory using the golden/magic triangle paradigm which means that students (and staff for that matter) use their Active Directory account to log onto the Macs.

The integration was quite easy – bind to Active Directory using Directory Utility (OS X 10.5 and below) or the Accounts preference pane in System Preferences (OS X 10.6), then bind to Open Directory. The Open Directory master server is also bound to Active Directory, and is then configured as an Open Directory master. This is known as a golden/magic triangle – both server and clients are bound to both directory services. Clients can then be managed using the OS X Server based upon their Active Directory group membership – you create Open Directory groups, assign Active Directory groups as members, and then configure preferences on that Open Directory group.

Everything was swell in integration land except for one thing – when users logged onto the Macs, the only group the Mac recognized the user as being apart of was Domain Users (specifically, the primary group). What then ensued was a few hours of troubleshooting and head scratching, trying to determine exactly why the Macs weren’t receiving the ‘full picture’ of the Active Directory user.

Troubleshooting started with the usual lead – checking the event log for anything that jumps out. In this case, I opened Console.app and checked the All Messages log and Directory Service logs – no issues. This is where the headaches started – without understanding how the authentication process works, it’s hard to determine where to look next. This is one of the main reasons why I like to understand *how things work* to a particular extent, rather than simply remembering a procedure on how to configure software/hardware or resolve an issue. Initially, and I don’t know why I thought this, I believed that the Macs were rather ‘primitive’ in the whole scenario and did a bind to LDAP with the entered credentials – if the bind succeeds, perform some more LDAP calls to determine more information about the user (such as group membership) and log the user in, if it fails then the credentials entered are incorrect.

Based on this theory, I checked the permissions on the Active Directory user object of the account I was testing with. In this example, testaccount. I checked the permissions on the testaccount object for the testaccount user and found that, as you would expect, testaccount can read the memberOf LDAP attribute (amongst others, but because this is a group membership issue I’m only interested in memberOf on user objects or member on group objects). Back to the drawing board, if you will. At this point I cracked out my trusty ol’ NETGEAR switch that does port mirroring – connected the iMac to the port I designated as SRC, my laptop to the port I designated as DST, and another port to the wall port as an uplink to the network. With this arrangement, ingress/egress traffic on the SRC port is copied to the DST port, for analysis using Wireshark. In particular, I wanted to see the LDAP calls the iMac was making to Active Directory and what Active Directory was returning to the iMac – that is, why is group membership information not being sent to the iMac. By default, the OS X Active Directory plug-in signs and encrypts LDAP packets. Thus, in order to read them I had to disable the signing and encryption using dsconfigad. Wireshark indicated that the LDAP calls being made returned standard attributes, givenName, sn, sAMAccountName, etc. but not memberOf. Interestingly, accounts that were members of Domain Admins did return memberOf attribute and group membership worked correctly. I compared the LDAP call for user account information for my account that was a member of Domain Admins and my test account – the call was identical so it wasn’t as if the iMac wasn’t requesting memberOf for my test account.

The next issue was to determine what account was being used to bind to LDAP. As per above, until now, I assumed the LDAP calls were being performed by the user authenticating to the Mac. This lead me off the track of believing it to be a permission issue. Even though packet signing and encryption were disabled the Mac doesn’t perform a simple LDAP bind (pass credentials over clear-text) and instead uses Kerberos to authenticate. Thus, there was no easy way to determine what account was being used to bind. I then enabled LDAP debugging (I can’t remember the registry key – will have to update post) and each LDAP bind (and call) was logged to the Event Log. What I then saw was that the computer account for the iMac was being used to bind to LDAP. This was a big ‘doh!’ moment for me, because this seems immediately obvious – when binding an Mac OS X system to Active Directory it creates a computer account – it doesn’t do this for no reason, it’s used for something, and in this case it’s used for the secure channel between it and the domain controller. I then did an Effective Permissions check again on my test account and found that the computer object could indeed NOT read the memberOf attribute. I decided to create a virtual machine and create my own test Active Directory domain and found that, by default, computer objects can read ALL properties on user objects, including memberOf. Thus, the issue was with the permissions in our production Active Directory.

Active Directory (and the entire network) is something we have inherited from the previous IT Department. After a bit more research and trial-and-error, I determined that by default Authenticated Users is a member of the Pre-Windows 2000 Compatible Access group and by default, this group is granted the Read all properties permission, among others, on user objects. Thus, any user or computer (or any other security principal) can read all properties on user objects in Active Directory. In our case, Authenticated Users wasn’t a member of the Pre-Windows 2000 Compatible Access group. After adding Authenticated Users back to the Pre-Windows 2000 Compatible Access group, everything was rosy – group membership was pulled correctly and client preferences were correctly managed based upon Active Directory group membership.

In this case, for whatever reason, the previous IT Department changed the group membership of a built-in Active Directory group without documenting it. This, for me, is a huge mistake as built-in groups are granted number of permissions by default on any number of objects in Active Directory and by changing this membership there is the potential to break things and in this case it did. It also made me realize that it’s a bit disappointing that vendors don’t supply more information on how things work (a primer on how OS X communicates with Active Directory would be good – to save troubleshooting time), and default settings (default group membership, ACL entries, etc. for Active Directory).

My next post will cover a Bash script to add printers as part of an image restoration workflow using DeployStudio. Surprisingly I couldn’t find any information on how to do this online. This may be because it’s so simple it’s obvious and thus there’s no need to document it, or because people deploy their printers to their Macs in a different manner (maybe using Managed Preferences – I’ve tried this in the past without luck as it used the Generic PostScript Driver rather than the proper print driver). I’ll then return to my coverage on how Cisco IP phone boot.

Until next time,

Josh