Open Directory (OD)

Open Directory is essentially Apples way of handling large scale authentication, system and user management. It is based off LDAPv3 and integrates with a variety of other authentication protocols such as:-

flat files
active directory
NIS
other LDAP servers

It also provides a way to easily setup Kerberosv5. Unlike normal uses of LDAP systems which comprises mainly of Address Books, as well as normal Authentication, Apple uses the very same system to also store user configurations, system setup preferences, mount point and configuration information and many more. While this makes LDAP a little slow due to the large number of records, it provides a very standard way of being able to access the data off any system. It is therefore possible to map LDAP entries from the Mac into any other system.

The LDAP based configuration also allows administrators to be able to login from any point in the network to perform management if required to do so. Replication and synchronization is also possible.

Open Directory Setup and Replication notes

Setting OD is relatively straight forward and doesn’t require too much configuration if the defaults are to be used. Unless you want to setup Kerberos, simply selecting OD setup within Server Admin tool is enough to get the OD up and running. Setting up replication of OD servers is also a simple case of selecting the option in Server Admin.

Changing passwords for users in the terminal can be done with either

passwd, or
kpasswd

I have also come across web based password changing applications such as

OSXPass (http://sourceforge.net/project/showfiles.php?group_id=102051)
MOSXSWebPassword (http://ps-enable.com/software/MOSXSWebPassword.dmg/view)

Of the above, i prefer the former to the latter as it does not use Web Objects.

In either case, the password will be synced going through the password service. If replication is setup, it can take as long as 8 minutes or even longer before the passwords can be synced to all the replicas. In some of the testings that is done by customers, they have found that the optimal number of replicas for a tolerable update time (perhaps 5-8 minutes) is 3 replicas. Anything more than that seems to take a much longer time to replicate. The log files are located in:-

/Library/Logs/PasswordService
/Library/Logs/slapdconfig.log

These two files will provide alot of clues on the activities of OD as well as issues if they should arise.

Some other K-base articles includes

Oversights during a OD tear down

As everything is directory dependent, I have made some mistakes during OD tear down resulting in weird configurations which needs cleaning up. Mainly, the job would be to review the environment and to remove all Directory configurations of share points before the teardown begins. Not doing so will result in many rouge entries which you cannot clean up after.

However, if it so happens that there are rouge entries, after reverting the OD master to standalone configuration, you can use Workgroup Manager tool, and set to “show all”. Following that, check the “Share Points” directory data and remove unwanted entries.

Also remember to check up the actual IP addresses of the various replicas and remove them first. Take note of the exact interface that the replication is going through in the log files. I have encountered that depending solely on the Server Admin tool’s report of IP can be wrong.

Re-Importing Users

Within the Server Admin tool, there is a archive and restore ability which can be used to backup the OD settings. While i have successfully tried that out in a classroom environment, i have yet to try it in a live environment.

Within the Workgroup Manager tool, there is another ability to export users. However, the exporting of these users will cause everyone to lose their passwords. Whiel i have so far been able to re-import the users list successfully, there has always been problems after. These problems includes:-

the directory admin (diradmin) losing its ability to login to the domain from workgroup manager
users not being able to login after re-import

Directory Admin being unable to login

In this case, there seems to be some error during the import that completely knocks out the original setup diradmin password. The way to prevent this is by:-

During the export of the user list from the original OD, ensure that the diradmin entry is NOT exported
If you don’t have the luxury to re-export, edit the exported file and examin the entries. Remove the block of entires that corresponds to the diradmin user.

However, you will find that even after that, it is still not possible to login from the Workgroup Manager tool. Don’t worry, the diradmin password is still correct, but somehow, it can’t login. To get around this, use the root user name and its password to login to the Workgroup Manager tool. Once authenticated, login to the directory by selecting the “lock” icon near the top right, and use the diradmin username and password. You will find that you will be authenticated and logged in. From there, you will be able to make all the required changes to the directory as per normal.

I have no idea why you have to use the root user to login to Workgroup Manager initially, but the above method works for me.

Note: Remember to reboot the machine when changes are made to the directory as the config settings are picked up only during boot time.

Users unable to login after re-import

This happens as the user list is exported without passwords. One will find that under “Advanced” in Workgroup Manager, all the user passwords will be “Crypt Passwords”. All that needs to be done is to reset them to “Open Directory” Passwords and everything will be ok.

I have heard of a tool called Passenger from http://macinmind.com/. But i have yet to be able to use it successfully.

Once done, the user should be able to login to CLI and change passwords as per normal. However, like mentioned before, if many replicas are used, it will take some time for all the passwords to sync up.