People who have managed Open Directory and will be moving to Synology will note that directory services really aren’t nearly as complicated was we’ve made them out to be for years. This is because Apple was protecting us from doing silly things to break our implementations. It was also because Apple bundled a number of seemingly disparate technologies into ldap. It’s worth mentioning that LDAP on a Synology is LDAP. We’re not federating services, we’re not kerberizing services, we’re not augmenting schemas, etc. We can leverage the directory service to provide attributes though, and have that central phone book of user and group memberships we’ve come to depend on directory services to provide.

To get started, open the Package Center and search for Directory. Click Install for the Directory Server and the package will be installed on the Synology.

When the setup is complete, open the Directory Server from the launcher available in the upper right hand corner of the screen. 

The LDAP server isn’t yet running as you need to configure a few settings before starting. At the Settings screen, you can enable the LDAP service by checking the box to “Enable LDAP Service” and providing the hostname (FQDN) of the service along with a password.


Once the service is configured, you’ll have a base DN and a bind DN. These are generated based on the name provided in that FQDN field. For example, if the FQDN is “synology.krypted.com”, its Base DN will be “dc=synology,dc=krypted,dc=com”. And the Bind DN would add a lookup starting a root, then moving into the users container and then the hostname: uid=root,cn=users,dc=synology,dc=krypted,dc=com

If this is for internal use, then it’s all setup. If you’ll be binding external services to this LDAP instance, make sure to open ports 389 (for LDAP) and/or 636 (for LDAP over SSL) as well. 

Once you have information in the service, you’ll want to back it up. Click on Backup and Restore. Then click on Configure.

At the Configure screen, choose a destination.

I prefer using a directory I can then backup with another tool. Once you have defined a place to store your backups using the Destination field, choose a maximum number of backups and configure a schedule for the backups to run (by default backups run at midnight). Then click OK. You now have a functional LDAP service. To create Groups, click on the Group in the left sidebar. 

Here, you can easily create groups by clicking on the Create button. At the wizard, provide a group name and then enter the name of a group (accounting in this example).

Click Next, then Apply to finish creating the group. One you have created your groups, click on User to start entering your users. Click Create. At the User Information screen, enter the name, a description if needed, and the password for a user. You can also restrict password changes and set an expiration for accounts. Click Next to create the user. 

At the next screen, choose what groups the new user will be in and click Next.

Enter any extended attributes at the next screen, if you so choose (useful for directories).

Click Next and then Apply.

For smaller workgroups, you now have a functional LDAP service! If you’d like a nice gui to access more options, look at FUM ( 

https://github.com/futurice/futurice-ldap-user-manager ), LAM ( https://www.ldap-account-manager.org/lamcms/ ), LinID ( http://www.linid.org/welcome/index.html )or other tools. I wrote an article on LDAP SACLs awhile back, so I’ll try and track that down and update it for Synology soon!

Lion brings with it a few challenges for administrators. One such is migrating the wiki service into the new format. When doing an upgrade in place, the Wiki service is pretty straight forward to upgrade, but in many cases, due to aging hardware, wiki services are moving from an older computer to a newer computer. This can be done in one of two ways. The first is to “migrate” the data by copying the Collaboration folder onto the new system. The second is to “export” and “import” the data. I usually recommend doing a migrate where possible, so we’ll start with that method. Note: Before getting started, make sure that the directory services side of things is good. If a user or group lookup for an object that owns, edits or has commented on a wiki fails then that wiki probably shouldn’t be migrated. Use the dscl or id commands to confirm that lookups are functioning as intended. To migrate wikis from one server to another, first copy the Collaboration directory to the new server. In this example, the directory has been dropped onto the desktop of the currently logged in user. To migrate the data once copied, use the wikiadmin command, along with the migration option. The option requires the path to the Collaboration folder, defined with -r, as follows: sudo wikiadmin migrate -r ~/Desktop/Collaboration When moving wikis, you can take the opportunity to get rid of a few you don’t want (such as that test wiki from way back when). Or administrators may just choose to move a single wiki to a new server in order to split the load across multiple hosts. When doing so, use the same command as earlier, along with the name of each wiki that is being moved, along with the -g option. For example, if moving the Legal wiki: sudo wikiadmin migrate -r ~/Desktop/Collaboration -g Legal The second way of moving wikis around is to export and then import them. To do so, first export wikis on the old server, using the wikiadmin command along with the export option, which requires an –exportPath option and needs to be done, on a wiki-by-wiki basis. So to export that Legal wiki to a file called LegalWikiTMP on the desktop: sudo wikiadmin export -g Legal --exportPath ~/Desktop/LegalWikiTMP Next, copy the wiki to the new server and import it, using the import option along with –importPath to identify where the file being imported is located. Using the same location, the command would then be: sudo wikiadmin import -g Legal --importPath ~/Desktop/LegalWikiTMP Note: The ability to import a wiki also allows for an API of sorts, as you can programmatically create wikis from other sources. The ability to export also provides a way to move into another wiki tool if you happen to outgrow the options provided in OS X Server and need to move to something more robust. There is another way to move wikis, using pg_dump, copying the data and then using pg_restore to import the data once you’ve created the tables.  This way is, in my opinion, the last resort if the standard wikiadmin commands aren’t working. In my experience, if I’m doing the migration this way then I’ve got other, bigger issues that I need to deal with as well. These commands work best when the wiki service has been started so that the databases are fully built out. To start the wiki service from the command line, use the serveradmin command instead of the wikiadmin command. The serveradmin command is used with the start option and then wiki is used to indicate the wiki service, as follows: sudo serveradmin start wiki The service can also be stopped, swapping out the start option with a stop option: sudo serveradmin stop wiki Finally, in a few cases (this is the main reason I’m writing this article), the attachments to wikis don’t come over during a migration. To migrate the files that are used for QuickLook, downloading attachments, etc, use the serveradmin command to locate the directory that these objects are stored in: sudo serveradmin settings wiki:FileDataPath The output identifies the directory where these objects are stored. Placing the contents in the same relative path as they are to the output of the same command on the target server usually results in restoring them. Once moved, use the fixPermissions option to repair the permissions of any files from the source (if any changes to account IDs are encountered such as an export/import rather than an archive/restore in OD this can lead to odd issues: sudo wikiadmin fixPermissions Also use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired: sudo wikiadmin rebuildSearchIndex And finally use resetQuicklooks to clear any cached Quicklook representations of objects that have been inserted into a wiki and might not display properly using Quicklook (you know you might need to do this if they look fine when downloaded but look bad with Quicklook even though QuickLook on the server can view the files just fine): sudo wikiadmin resetQuicklooks When done properly the migration can take awhile. Keep in mind that every tag, every article, every edit to every article and basically everything else is tracked inside the tables that you’re moving. While there might not be a ton of data in the Collaboration directory or in an export, all of the data needs to go to the right location. This can take a little time in environments that have a lot of articles, even if they’re really short articles…