Setting Up An Open Directory Replica In Yosemite Server

Previously, we looked at setting up an Open Directory Master in OS X Server. An Open Directory Replica keeps a copy of the Open Directory database available for users even when the Master goes offline. But it can also take a part of the load from the Open Directory Master and when using the new Locales feature, balance network traffic. To get started with an Open Directory Replica, first enable SSH, now disabled by default. Next, use the changeip to check the host name. While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In OS X Server, I’ve seen each find things that other misses. Additionally, in Yosemite and above, OS X Server now requires to be able to lookup whatever the hostname is set to in order to actually promote either to a replica or a master. To use changeip to verify the hostname is set appropriately: sudo changeip -checkhostname The address and host names should look correct and match what you see in the Server application’s Next Steps drawer. Primary address = Current HostName = DNS HostName = The names match. There is nothing to change. dirserv:success = “success” Provided everything is cool with the hostname, use the slapconfig command to preflight a replica prior to promotion. The syntax there is the same as the -createreplica syntax, used as follows, assuming the master has an IP address of /usr/sbin/slapconfig -preflightreplica diradmin Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica. odr1Then, click on the Open Directory service. odr2Then, use the ON button to start the configuration process. When prompted, click on “Join an existing Open Directory domain as a replica” and click on the Next button. odr3When prompted, enter the parent Open Directory server’s host name (likely the name of the Open Directory Master), directory admin user name (the diradmin or custom username provided when Open Directory was configured), and then the directory admin password. odr4 Then click on the Next button again to setup the services.


At the Confirm settings screen, click on the Set Up button and the replica is completed provided there are no issues with the configuration. Check Server app on both the Replica and the Master and verify that the server is displayed under the Master.

odr6 Once you’ve created your first replica, you can then start to define replica trees, where each replica looks at one above it, which then looks at another. I’ll do another article later on replica trees. Note: If there are any problems during promotion, I start over every time using slapconfig along with the -destroyldapserver option to nuke everything in OD: sudo slapconfig -destroyldapserver Use the logs to help if you’re having replica creation problems. These can be added using the -enableslapdlog option: sudo slapconfig -enableslapdlog You can use the -addreplica option to add replicas manually while running tail on the slapd logs: sudo tail -f /var/log/slapd.log Once the replica has been created, you can add more and more until you exceed 32. At that point, you have a fairly large Open Directory environment and you go to add the 33rd replica but you get a funny error that dserr doesn’t have listed. The reason is likely that a single Open Directory Master can only have 32 replicas – and the fact that you’ve made it that far means you get a cookie. Cookie or no, you can have 32 replicas on each replica (thus having a replica tree), ergo allowing for a total of 1,024 replicas and a master. So rather than bind that 33rd replica to a master, move to a replica tree model, trying to offload replicas in as geographically friendly a fashion as possible (thus reducing slap traffic on your WAN links) by repositioning replicas per site. Similar to how Active Directory infrastructures often have a global catalog at each site, if you’ve got a large number of Open Directory Replicas then you should likely try and limit the number that connects back to each master per site to 1. Assuming that each replica can sustain a good 350 clients on a bad day (and we always plan for bad days), even the largest pure Mac OS X deployments will have plenty of LDAP servers to authenticate to. However, you’re likely going to have issues with clients being able to tell which Open Directory server is the most appropriate to authenticate through. Therefore, cn=config will need to be customized per group that leverages each replica, or divert rules used with ipfw to act as a traffic cop. Overall, the replica trees seem to be working fairly well in Snow Leopard, netting a fairly scalable infrastructure for providing LDAP services. You can also get pretty granular with the slurpd (the daemon that manages Open Directory replication) logs by invoking slurpd with a -d option followed by a number from 4 to 65535, with intensity of logs getting more as the number gets higher. You can also use the -r option to indicate a specific log file. If you have more than 32 replicas then it stands to reason that you also have a large number of objects in Open Directory, a fair amount of change occurring to said objects and therefore a fair amount of replication IO. In order to offload this you can move your replication temp directory onto SSD drives, by specifying the -t option when invoking slurpd. The slurpd replication occurs over port 389 (by default). Therefore, in a larger environment you should be giving priority to network traffic. If you choose to custom make/install slurpd then you’ll also need to go ahead and build your Kerberos principles manually. In this case you would get a srvtab file for the slurpd server and then configure slapd to accept Kerberos Authentication for slaves. Having said this, I haven’t seen an environment where I had to configure slurpd in this fashion.

Rock the Logging Facilities in Windows Server (aka More Syslog Crap)

The default logs in Windows Server can be tweaked to provide a little better information. This is really helpful, for example, if you’re dumping your logs to a syslog server. Here’s a script that can make it happen with a few little tweaks to how we interpret data (to be run per host, just paste into a Powershell interface as an administrator): auditpol /set /subcategory:"Security State Change" /success:enable /failure:enable auditpol /set /subcategory:"Security System Extension" /success:enable /failure:enable auditpol /set /subcategory:"System Integrity" /success:enable /failure:enable auditpol /set /subcategory:"IPsec Driver" /success:disable /failure:disable auditpol /set /subcategory:"Other System Events" /success:disable /failure:enable auditpol /set /subcategory:"Logon" /success:enable /failure:enable auditpol /set /subcategory:"Logoff" /success:enable /failure:enable auditpol /set /subcategory:"Account Lockout" /success:enable /failure:enable auditpol /set /subcategory:"IPsec Main Mode" /success:disable /failure:disable auditpol /set /subcategory:"IPsec Quick Mode" /success:disable /failure:disable auditpol /set /subcategory:"IPsec Extended Mode" /success:disable /failure:disable auditpol /set /subcategory:"Special Logon" /success:enable /failure:enable auditpol /set /subcategory:"Other Logon/Logoff Events" /success:enable /failure:enable auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable auditpol /set /subcategory:"File System" /success:enable /failure:enable auditpol /set /subcategory:"Registry" /success:enable /failure:enable auditpol /set /subcategory:"Kernel Object" /success:enable /failure:enable auditpol /set /subcategory:"SAM" /success:disable /failure:disable auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable auditpol /set /subcategory:"Application Generated" /success:enable /failure:enable auditpol /set /subcategory:"Handle Manipulation" /success:disable /failure:disable auditpol /set /subcategory:"File Share" /success:enable /failure:enable auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable auditpol /set /subcategory:"Other Object Access Events" /success:disable /failure:disable auditpol /set /subcategory:"Sensitive Privilege Use" /success:disable /failure:disable auditpol /set /subcategory:"Non Sensitive Privilege Use" /success:disable /failure:disable auditpol /set /subcategory:"Other Privilege Use Events" /success:disable /failure:disable auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable auditpol /set /subcategory:"Process Termination" /success:enable /failure:enable auditpol /set /subcategory:"DPAPI Activity" /success:disable /failure:disable auditpol /set /subcategory:"RPC Events" /success:enable /failure:enable auditpol /set /subcategory:"Audit Policy Change" /success:enable /failure:enable auditpol /set /subcategory:"Authentication Policy Change" /success:enable /failure:enable auditpol /set /subcategory:"Authorization Policy Change" /success:enable /failure:enable auditpol /set /subcategory:"MPSSVC Rule-Level Policy Change" /success:disable /failure:disable auditpol /set /subcategory:"Filtering Platform Policy Change" /success:disable /failure:disable auditpol /set /subcategory:"Other Policy Change Events" /success:disable /failure:enable auditpol /set /subcategory:"User Account Management" /success:enable /failure:enable auditpol /set /subcategory:"Computer Account Management" /success:enable /failure:enable auditpol /set /subcategory:"Security Group Management" /success:enable /failure:enable auditpol /set /subcategory:"Distribution Group Management" /success:enable /failure:enable auditpol /set /subcategory:"Application Group Management" /success:enable /failure:enable auditpol /set /subcategory:"Other Account Management Events" /success:enable /failure:enable auditpol /set /subcategory:"Directory Service Access" /success:enable /failure:enable auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable auditpol /set /subcategory:"Directory Service Replication" /success:disable /failure:disable auditpol /set /subcategory:"Detailed Directory Service Replication" /success:disable /failure:disable auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable auditpol /set /subcategory:"Other Account Logon Events" /success:enable /failure:enable auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable eventviewer

Configuring Windows 2008 As An NTP Server

When you’re configuring a Mac to leverage an existing Windows infrastructure, having the clocks in sync is an important task. Luckily, Windows Server has been able to act as an NTP server for a long time. In this article, we’ll look at configuring Server 2008 R2 to be an NTP server for Mac and Linux clients. Note: Before you get started, or any time you’re hacking around in the registry, make sure to do a backup of your registry/SystemState! To enable NTP on Windows Server, open your favorite registry editor and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpServer. From here, enter a key called Enabled as a dword with a value of 00000001. The NTP Server should look upstream at another NTP host. To configure this, go ahead and navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient and create Enabled as a dword with a value of 0000001 and SpecialPollInterval with a value of 300:
“Enabled”=dword:00000001 “SpecialPollInterval”=”300”
NTP would then need a source, so let’s go ahead and create that in the registry as well. To set that up, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters and then setup the Type key to contain NTP, the Period key to contain freq and the NtpServer key to obtain the IP address of the server followed by ,0x1, as follows (assuming an IP of for the upstream NTP server:
“NtpServer”=,0×1” “Type”=”NTP” “Period”=”freq”
The w32tm service doesn’t start unless your system is on a domain (and should be restarted if the system is already running as a DC). To starts the service automatically (if needed), use the sc command: sc triggerinfo w32time start/networkon stop/networkoff Windows systems can also use an NTP server. To configure the NTP client, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeTimeProvidersNtpClient and create Enabled as a dword with a value of 0000001 and SpecialPollInterval with a value of 300:
“Enabled”=dword:00000001 “SpecialPollInterval”=”300”
NTP would then need a source, so let’s go ahead and create that in the registry as well. To set that up, navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW32TimeParameters and then setup the Type key to contain NTP, the Period key to contain freq and the NtpServer key to obtain the IP address of the server followed by ,0x1, as follows (assuming an IP of for the upstream NTP server:
“NtpServer”=,0×1” “Type”=”NTP” “Period”=”freq”
Finally, you can invoke the w32tm service directly to query peers and verify that no skew has occurred with the clocks: w32tm /query /peers Viola, you’ve now achieved what could be done using a checkbox on an OS X Server. Hope you’ve enjoyed noodling around in the registry!

Configuring Time In OS X Mountain Lion & OS X Mountain Lion Server

Time is a very important aspect of OS X Server, as it has been since the early days. Time is so important that if you see network time server, NTP or 5 minutes as the answer on an Apple exam, you should just pick that one, as it’s invariably correct. The traditional way to configure time zones and Network Time Servers is to use systemsetup command. Before you set a time zone, run the following to see a list of all available time zones, use the -listtimezones option in systemsetup: sudo systemsetup -listtimezones To set the time zone, pick one and use the -settimezone option in systemsetup: sudo systemsetup -settimezone "America/Chicago" To check the current time, then run -gettime: sudo systemsetup -gettime The -settime option can then be used to set the time, although it’s invariably better to set the time zone automatically with a network time protocol (NTP) server, using the -setnetworktimeserver option: sudo systemsetup -setnetworktimeserver You would then need to turn using NTP servers on, using -setusingnetworktime option and setting the value there to on sudo systemsetup -setusingnetworktime on Now let’s look at a different way to do this. Run the following, in OS X Server: sudo serveradmin settings info:timeZone = "America/New_York" That shouldn’t work. Now ya’ know, OS X Server isn’t fully matured yet, so they’ll get around to it… But what does work is setting the NTP server and enabling NTP services. To enable NTP: sudo serveradmin settings info:ntpTimeServe = yes To set the NTP server: info:ntpServerName = "" Note: The NTP server must be accessible when set.

Setting Up an Open Directory Master in OS X Mountain Lion Server

Open Directory has never been so easy to setup for a basic environment as it is in OS X Mountain Lion Server. It’s also never been so annoyingly simple to use that to do anything cool requires a bunch of command line foo. No offense to the developers, but this whole idea that the screens that were being continually refined for a decade just need to be thrown out and started fresh seems to have led to a few babies thrown out along with them. Not often as I’m kinda’ digging most of the new config screens in OS X Mountain Lion Server, but with Open Directory, it’s just too easy. Features mean buttons. Buttons make things a tad bit more complicated to use than an ON/OFF switch… Anyway, rant over. Moving on. As with almost any previous version of OS X Server and Open Directory, once you’ve installed the Server app, run the changeip command along with the -checkhostname option to verify that the IP, DNS and hostname match. If (and only if as it will fail if you try anyway) you get an indication that “The names match. There is nothing to change.” then you can move on to setting up the service.
Note: There’s this thing called the Next Steps Drawer. No matter what it says, I still won’t proceed until changeip checks clean. 
To set up the Open Directory Master, open the Server app and click on the Open Directory service. From here, click on the ON button. For the purposes of this example, we’re setting up an entirely new Open Directory environment. At the “Configure Network Users and Groups” screen, click on “Create a new Open Directory Domain” and click on the Next button. At the Directory Administrator screen, enter a username and password for the directory administrator account. The default account is sufficient, although it’s never a bad idea to use something a bit less generic. Once you’ve entered the username and password, click on the Next button. Then we’re going to configure the SSL information. At the Organization Information screen, enter a name for the organization in the Organization Name field and an Email Address to be used in the SSL certificate in the Admin Email Address field. Click on Next. At the Confirm Settings screen, make sure these very few settings are OK with you and then click on the Set Up button to let slapconfig (the command that runs the OD setup in the background, kinda’ like a cooler dcpromo) do its thing. When the Open Directory master has been configured, there’s no need to reboot or anything, the indicator light for the Open Directory service should appear. If the promotion fails then look to the preflight options I wrote up awhile back. Once the promotion is complete, you’ll also see the server listed in the Servers list. Here, click on the server and click on the Global Password Policy option in the cog-wheel menu. This is where you can configure the parameters that passwords must meet in order to be usable on the system. Clicking on the minus (“-“) button while a server is highlighted runs a slapconfig -destroyldapserver on the server and destroys the Open Directory domain if it is the only server. All domain information is lost when this happens. Next, let’s bind a client. Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane. To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted.
Click on the Edit… button and then the plus sign (“+”). Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.
It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user. Provided everything works that’s it. The devil is of course in the details. There is very little data worth having if it isn’t backed up. Notice that the old Archive and Restore options are gone. To run a backup, run the slapconfig command along with the -backupdb option followed by a path to a folder to back the data up to: sudo slapconfig -backupdb /odbackups To restore a database (such as from a previous version of the operating system where such an important option was actually present) use the following command (which just swaps backupdb with -restoredb) sudo slapconfig -restoredb /odbackups Both commands ask you for a password to encrypt and decrypt the disk image created by them.

Install ntpd in Ubuntu Server 10

I’m sure you’re getting tired of seeing me regurgitate apt-get commands, but here’s another:
apt-get install ntp
This will install ntpd. Then a quick update to /etc/ntp.conf to configure who you get your updates from (I still like and you’re now an ntp server. Once changed, restart the daemon:
/etc/init.d/ntp restart
Then, use ntpq to check your time against the server:
ntpq -np
Lucky us, ntp is easy, but we’re gonna’ need it for Kerberos now aren’t we…

Only Use Kerberos with Podcast Producer

By default the /Library/Preferences/ allows basic, digest and Kerberos authentication. Attempts to authenticate will be made in the reverse order, respectively. This is pulled from the http_auth_type array, which you can see using the following command: serveradmin settings pcast You can then remove an entry and edit existing entries to change the supported mechanisms using serveradmin if you cannot stop the Podcast Producer service. If you can stop the service then the easiest way to edit the authentication mechanisms is to edit /Library/Preferences/ directly. To do so, locate the http_auth_type key as you see it here: <key>http_auth_type</key> <array> <string>basic</string> <string>digest</string> <string>kerberos</string> </array> Here, remove each string that you no longer wish to support. Removing all except Kerberos will provide support for only Kerberos as an authentication mechanism.

Ticket Viewer: What's in a Name Anyway? + Snow Leopard = Ticket Viewer. I’m not sure what the point of this is, but I’m guessing it will become clear some day. Possibly Apple plans on also integrating some other form of tickets? Curious, but easy to figure out quickly since the icon didn’t change…

Snow Leopard + SkyHook = Kerb Problems?

In the Date and Time System Preference pane there is now an option to enable “Set time zone automatically using current location”. Assuming you have a Mac OS X computer with Wi-Fi and you use this option (which is not enabled by default) then your portable looks up your location automatically using the wireless access points surrounding you, which can then be looked up against the Skyhook database API and then changes your time zone based on your physical location. However, if your system looks back to the IP address of the KDC and sees a time offset that is greater than 5 minutes a few people have asked me whether that could be problematic. The answer is no. Reason being that the time is relative, based on your time zone setting. Therefore, even if your computers time changes provided that the relative time to the time on the KDC (be it Active Director or Open Directory) is accurate then you should still be in good shape. Overall, this is a great new feature of Snow Leopard. It’s been integrated into Firefox as well (in your about:config page look for geo.enabled) and I’d expect to start seeing it on a number of devices and in a number of applications that can be geography-aware without having to implement GPS.

Samba 4: A Poor Mans Active Directory

Today I pulled down the Samba 4 binaries and installed it using the instructions the developers are slowly building on the Samba 4 wiki. Overall it was a fairly painless experience, although I do believe I have a couple of bug reports to file (not surprising considering it is not out yet). Overall I found the process to be far easier than it has been in the past. The Samba team seems to realize that in order for Samba 4 to compete with Active Directory that it needs to integrate really well in the *nix server ecosystem. For example, like Active Directory you can choose to have Samba integrate into your DNS infrastructure. However, the instructions call for manually editing gssapi to get bind to accept the updates from Samba. The instructions also end up having you comb through comments in the config files, a potentially daunting process. But once it was done I found the service records typically required for an Active Directory environment to be built out for me and easily managed. One place where things are really well done is the integration between Samba 4 and the Active Directory administration tools. The wiki clearly explains how to install the tools and then use them to manage objects and policies within their version of Active Directory. There is also the promise of upcoming SWAT integration but it is not yet ready for production so from a GUI standpoint you’ll still need to use the Windows tools. However, SWAT is somewhat available and allows for easy GUI administration without reverting to Microsoft tools for a number of items. The further development and integration of SWAT or a different product (which is more likely it seems) will likely be critical to divorcing Samba 4 from Windows administration tools and having it prosper more fully in the community. While the Samba team promises a more consistent and tightly integrated relationship between OpenLDAP and Samba, this is one place where the code doesn’t seem to be finished. For example, the documentation is still fairly non-existent, but supposedly you can leverage OpenLDAP to do multi-master replication with Samba. This represents a great feature that kills a lot of potential Samba rollouts, but not yet clear in terms of implementation. This extends to Kerberos for single sign on. I thought I was able to get it to work, but alas, I was mistaken. I’ll keep trying to figure this piece out and hopefully report back more on it in the future. The new ntp signing feature is nice, although if you have clients that do not support ntp signing then this can be a bit of a cause of concern. Windows clients worked easily, right out of the box. I ended up using ntp authentication without an issue as opposed to signing and was able to get Mac OS X to use the ntp server, with a little configuration of the ntp.conf file on the Mac. However, once bound I had to create a few service records to get Mac OS X to go ahead and join the domain properly. One thing I can say is that if you are interested in Active Directory you might just learn more about Active Directory in building out a Samba 4 infrastructure than you will likely learn by taking the Active Directory certifications. The reason for this is that you will begin to better understand what is going on in the back end. If you cannot bind a Mac OS X client to your faux Active Directory and you, let’s say, fire up Wireshark to try and figure out why, you’ll notice that something is missing: maybe it’s repeated attempts to enumerate something, throwing DNS requests all over the place. In order to fix it you will suddenly need to understand what each of those records is there for and what settings to populate them with. Likewise, you might find that you understand what FSMO roles are really for when you have to essentially integrate a completely different piece of technology for each of them. This kind of research will teach you more than you might know… Overall, if you are going to put something like Samba 4 in production right now you might have a lot of growing pains. When it’s ready and it’s released then for Active Directory (or potential Active Directory) environments that don’t use the full compliment of Windows services it might very well be worth considering. However, currently it doesn’t support Exchange or other items that require extending an LDAP schema and so you might end up with a considerable amount of manual schema extensions in order to garner said support. The lack of a comprehensive set of GUI tools will keep a lot of Windows administrators away from Samba 4, but when their executives compare the steep cost of CALs to an open source tool then I’m guessing that some are going to start projects to determine if Samba 4 can work for them. Note: None of this would make and build properly in Mac OS X. I did all of my testing on a Red Hat VM using the source downloaded from the following: rsync -avz samba-master