You can destroy an LDAP server using the Server app (and still using slapconfig -destroyldapserver). To do so, open the Server app and click on Open Directory. Then click on the Open Directory server in the list of servers.
When prompted to destroy the LDAP Master, click on Next.
When asked if you’re sure, click Continue.
When asked if you’re really, really sure, click Destroy.
krypted January 19th, 2015
Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
Apple, directory services, MAC, Mac OS X, Open Directory
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 = 10.0.0.1
Current HostName = odr.krypted.com
DNS HostName = krypted.com
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 172.16.2.23:
/usr/sbin/slapconfig -preflightreplica 172.16.2.23 diradmin
Provided that the server is ready, open the Server app on a freshly installed computer you want to be your Open Directory replica.
Then, click on the Open Directory service.
Then, 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.
When 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.
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.
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.
krypted October 16th, 2014
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
10.10, directory services, kerberos, LDAP, MAC, OpenLDAP, OS X Server, setup open directory replica, slapconfig, yosemite, yosemite server
The chapters from my upcoming Take Control book keep rolling into the TidBits website. The next installment is Chapter 4: Directory Services, which can accessed at http://tidbits.com/article/14821
Hope you enjoy!
krypted June 10th, 2014
Posted In: Articles and Books, Mac OS X, Mac OS X Server
Books, directory services, MAC, Open Directory, OS X Server, take control, tidbits
You’ve got Open Directory running and humming beautifully in Mavericks Server (Server 10.9). You show up to work and the hard drive has died on that perfectly configured Open Directory Master. Luckily, you have a replica and you have an archive of your Master. You can restore or you can promote your Replica to a Master. What to do? Well, I can’t tell you what you should do, but I can tell you that Apple has planned for this. Here, we’re going to look at promoting that Replica to a Master. Because after all, hard drives fail. Let’s look at what all this looks like.
Create An Open Directory Archive
In order to properly restore an Open Directory Master or promote a Replica to a Master, you’ll need the SSL keys. You should also just keep archives of your Open Directory environment around (albeit in a secure location) because you really never know. To create an Open Directory Archive, which has the keys in it as well as data needed to restore a Master, first open the Server app. From within the Server app, click on the Open Directory service.
Towards the bottom of the screen, click on the cog wheel icon. At the menu, click Archive Open Directory Master…
When prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button.
At the Archive Open Directory Master screen, choose a location to create your archive. Also, provide a password for the archive. Click the Next button when you’re ready to proceed.
At the Confirm Settings screen, click Archive. The archive is then created. Keep this safe as it has all your base are belong to us in it. You have to do this proactively. Once the hard drive in that Open Directory Master craps out, you’ll need the Archive to put the pieces of Humpty Dumpty back together again.
Promote A Replica To A Master
Provided you have a Replica and an Archive, promoting a Replica to a Master couldn’t be easier in Mavericks Server. To do so, open the Server app from the Replica and then use the cog wheel icon to bring up the menu.
Here, click Promote Replica to Master.
At the “Promote Open Directory replica to master” screen, provide an Open Directory username and password (e.g. diradmin with the appropriate password). Also, choose the archive you created previously. Then click Next. The Replica will become an archive. Once finished, remove any other replicas and repromote them.
Stop Open Directory
Another option is to stop Open Directory on the replicas until you can get your Master back up and running. To stop Open Directory, open the Server app and click on the Open Directory service.
Click on the OFF button. You’ll then be prompted to verify that you really want to stop directory services on the server. Click OK (which should probably read a bit more ominous, like “OMG, OK”.
The server is then stopped. To completely remove Open Directory from the server, run the slapconfig command, followed by -destroyldapserver:
Also, don’t forget to go to the Master and remove any servers from there as well, once they’ve been fully demoted.
krypted October 22nd, 2013
Posted In: Mac OS X Server
archive open directory, backup open directory, directory services, Mac OS X Server, mav server, mavericks, Mavericks Server, Open Directory Master, OS X Server 3.0, promote a replica to a master, server 2.2, server 3, slapconfig
Over the years, the terms Magic, Golden, Triangle, Augments, Directory, Domains and Active have given the administrators of Mac OS X environments fits. So when you think about using Active Directory to manage iOS devices through the Profile Manager service, built into Lion Server, you may think that it’s a complicated thing to piece together. You may remember those days when you had to manually craft service principals because xgrid wouldn’t play nice with Acive Directory, or you might think of twisting augmented records to support CalDAV. But you’re gonna’ have to forget all that, ’cause getting Profile Manager to talk to Active Directory is one of the easiest things you’ll do.
Before we get started, architecture. Every Profile Manager instance is an Open Directory Master. Apple has included a local group in Mac OS X Server called Profile Manager ACL. Users and groups from any directory domain that can be viewed in dscl can be added to this group. Adding objects to this group enables them to authenticate to the MyDevices portal but not administrate. Kerberos isn’t really used here, nor are nested groups. You’ll apply policies directly to Active Directory groups in Profile Manager. For many long-term Apple administrators, this paragraph is all you need to read. If not, please continue on.
To get started, first set Profile Manager up, as shown in a previous article I did
. Once configured, verify that Open Directory or local clients can authenticate, bind to Active Directory.
Bind to Active Directory
From within System Preferences, click on the Users & Groups System Preference pane and click on Login Options. Then click on the Edit… button for the Network Account Server. From here, click on the plus sign (“+”) and enter the domain name into the Server field.
Once bound, you will see the server listed. At this point, if you try to authenticate to the MyDevices portal as an Active Directory user, you will be able to authenticate, but you will not have permission to enroll devices. To log in, access the web service at the address of the server followed by /MyDevices (e.g. https://mdm.pretendco.com/MyDevices).
Provide the user name and password to the service. The Active Directory users are unable to access the MyDevices service.
Nest Groups Using Workgroup Manager
Click on Logout and we’ll fix this. There is no further configuration required for the Active Directory groups to function properly in regards to how they work with the server. However, we will need to open Workgroup Manager and nest some groups. You might think that you’d be doing something all kinds of complicated, but notsomuch. You also might think that you would be nesting the Active Directory users and groups inside Open Directory groups, given that you have to enable Open Directory in order to use Profile Manager. Again, notsomuch. To nest the groups, browse to the local directory and then then click on the com.apple.access_devicemanagement group.
Click on the lock icon to unlock the directory domain, authenticating when prompted.
Click on the Members tab and then click on the plus sign (“+”) to add members to the group.
Then in the menu that slid out, click on the domain browser at the top of that menu and select the Active Directory entry.
Drag the user or group from the menu into the list of members and then click on the Save button.
Now log in again using the MyDevices portal and you’ll be able to Enroll. From within Profile Manager (log in here as a local administrator), you’ll see all of the users and groups and be able to apply policies directly to them by clicking on the Edit button for each (the information isn’t saved in the directory service on the server, but is cached into the directory service client on the client when using Mac OS X 10.7, Lion based clients).
Moving Mac OS X Management From MCX
You keep hearing that you need to move some of your managed preferences to profiles (or Profile Manager in most cases), but you can’t really think about that until you get Profile Manager integrated with Active Directory, can you? And getting those pesky iOS devices working with Active Directory style policies has been on your radar, but really, who has time?
then have a few distinct benefits over Managed Preferences (MCX) for some, which we’ll look at through the lens of Profile Manager. The first is that they’re instant. You can make a change to a profile on a device enrolled in an MDM service and you instantly see the changes on the client (most profile settings that is, not all), rather than having to log the client out and then back in. You can also wipe and lock devices and the interface is easier (I mean, no nesting thankyouverymuch).
But there are a few drawbacks as well. You can’t cluster Profile Manager, so there are some benefits to using 3rd party services in a move to profile based management. You also manage settings using the Always option, rather than being able to use the Once or Often settings. You can use custom property lists, though and importantly, MCX is used to actually implement most of these profiles on client systems, so those skills you’ve been honing for managing Managed Client workflows will not be totally lost in the transition. Overall, I had initially thought that management by profile would be much less granular than management via managed preferences, but I’ve found ways around any issues and have found it’s actually much easier and works as reliably as dual directory or Active Directory based managed preferences worked.
krypted April 3rd, 2012
Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
Active Directory integration, Contact your system administrator., directory services, Groups, integration, Lion, Logout, Mac OS X Server, Magic Triangle, MyDevices, Open Directory, profile manager, You do not have permission to access the page you were looking for.
Scripting directory services events is one of the most common ways that the OS X community automates post-imaging tasks. As such, there are about as many flavors of directory services scripts are there engineers that know both directory services and have a little scripting experience. In OS X Lion, many aspects of directory services change and bring with them new techniques for automation. The biggest change is the move from DirectoryService to opendirectoryd.
In Snow Leopard and below, when you performed certain tasks, you restarted the directory services daemon, DirectoryService. The same is true in Lion, except that instead of doing a killall on DirectoryService, you do it on opendirectoryd:
Also, local account passwords in OS X have been moved into attributes within user account property lists and so there is no longer a /var/db/shadow/hash directory. Therefore, copying property lists and their associated password hash file is no longer a necessary process.
dsperfmonitor vs odutil
Next, dsperfmonitor has gone to the great binary place in the sky to join dirt and DirectoryService. It is somewhat replaced with odutil. The odutil command is pretty easy and straight forward. You can see all open sessions, nodes, modules, requests, statistics and nodenames using the show verb (along with those subcommands). You can also set the logging level for directory services to alert, critical, error, warning, notice, info and debug, each with more and more events that are trapped. This is done with the set log verb along with the level (which is by default set to error):
odutil set log debug
The odutil command is also used to enable statistics. These are pretty memory intensive (or they were on a mini w/ 4GB of memory in it but might not be with your 32GB of RAM fortified Xserve). This is done using odutil’s set statistics verb w/ an option of either on or off:
odutil set statistics on
Note: It’s worth noticing that stats are persistent across restarts, so don’t forget to turn it off.
For Open Directory administrators, you’ll be elated to know that your LDAP bind script just got a bit shorter. Now, search policies are updated automatically when binding via dsconfigldap. But, if you have a bunch of scripting that you don’t want to rip apart you can still do search policies manually by using the spiffy new -S option for dsconfigldap (yes, I just insinuated that -S was for spiffy, what’s it to ya’?!?!).
scutil can now be used to view Active Directory Kerberos information. scutil can also be used to query the search node and interface states. klist no longer seems to function properly, so use ktutil to with a list verb to see service principals:
Not to be left out, the Active Directory binding tool, dsconfigad, got some new flair as well (yes, I just insinuated that dsconfigad was really Jennifer Aniston’s contribution to OS X and I challenge you to prove me wrong). There is now a -restrictDDNS option, which I’m sure you can guess disable dynamic DNS registration in Active Directory-integrated DNS zones. There’s also the rockin’ new -authority option, which enabls or disables Kerberos authority generation. Finally, dsconfigad gets some minor cosmetic changes. -f becomes -force, -r becomes -remove, -lu becomes -localuser, -lp becomes localpassword, -u becomes username, -p becomes -password, but the original options still work. Who knows how long the old operators will stick around, but my guess is they’ll be around until dsconfgad isn’t…
Most options and settings for the AD plug-in should now be configured following the AD bind process (thanks to @djstarr for that little addition). How does this impact your scripts. Just move the settings to the bottom of the script if they give you gruff… Also, the -enableSSO option has been changed to -enablesso.
Finally, defaults allows you to put the .plist in the command when you use a file path to list them out. This should eliminate the 6 backspaces we often had to type to test certain things after auto-completing file names… 🙂
krypted July 20th, 2011
Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
Active Directory, bash, changes in scripts, directory services, dsconfigad, dsconfigldap, dsperfmon, Mac OS X, Open Directory, opendirectoryd, OS X Server, scripting, Shell
DSDebug is a small, quick little tool that just puts a server into Directory Services debug mode, waits for a specified amount of time and then drops a file on your desktop with the logs, placing the server back into a non-Directory Services debug mode. That’s all. It’s mostly designed to send to an Open Directory server’s administrator, tell them to double-click on it and not have to step anyone through typing much. It waits mostly so you can know how long it’s going to wait… Nice, small and compact. In the future I will likely build in a pattern matcher with some known, common errors, color coding, etc (or maybe I’ll forget like I sometimes do) but for now it fits my need so I thought it might fit yours as well… Oh, and it cleans up after itself, deleting the DirectoryService.debug.log file in case you captured a massive log or want to run it later without a bunch of crap already in the file…
Click here to Download DSDebug
DSDebug will be made on available on the Apps page as well.
krypted January 22nd, 2010
Posted In: Active Directory, Mac OS X Server
automated, debug mode, directory services, GUI, Open Directory
In a number of contexts, we hear about directory services plug-ins. A directory services plug-in is a way for a Mac OS X computer to leverage the DirectoryServices daemon to obtain account information (be it authentication or policy information) from a server. This might be an Active Directory server that uses the Active Directory Plug-in or an Open Directory server that uses LDAP.
You disable plug-ins that you don’t need and enable plug-ins (ie Active Directory plug-in or third party plug-ins) that you need in order to access directory services of various types. These plug-ins are developed in the form of .dsplug files. The default plug-ins that Apple includes with Mac OS X are located in the /System/Library/Frameworks/DirectoryService.framework/Versions/A/Resources/Plugins folder in Mac OS X. Any .dsplug file stored in this directory will be loaded as a plug-in, assuming it matches the parameters laid out in the DirectoryServices API.
By opening up the plug-in architecture (thus a plug-in rather than just a daemon) Apple has then left room for third party developers to provide solutions that supplement the tools that Apple has included in the operating system. Thus, companies like Thursby, Quest, Likewise and Centrify have all provided ways of extending the usefulness of third party directory services.Third party plug-ins are typically installed in the /Library/DirectoryServices/PlugIns directory of a computer, which is where you will find plug-ins for Quest and products from Thursby. Again, by virtue of a .dsplug being stored in this location the DirectoryServices daemon will load the plug-in. Likewise chooses to store their .dsplug in the same place that Apple stores theirs, which is likely just accidental (although confusing when you’re researching how their plug-in works) – but the plug-in works just fine in either location.
You won’t typically run plug-ins you do not need. Some, such as the Local plug-in cannot be disabled (then you couldn’t have local accounts to run services after all). Plug-ins can be enabled or disabled in the Directory Utility, clicking on the Services icon in the toolbar. When you do so you’re editing the /Library/Preferences/DirectoryService/DirectoryService.plist, either toggling strings to Inactive or Active (which seems like it should be boolean btw, but that is another story). When a plug-in has been set to inactive the Daemon will skip loading it. But it is still stored in the same place. Because a plug-in’s active vs. inactive nature is stored in this property list we can then programatically enable or disable it using the defaults command. For example, to enable the Active Directory plug-in you would use the following command:
defaults write /Library/Preferences/DirectoryService/DirectoryService “Active Directory” “Active”
Once the plug-ins are enabled or disabled we can then use them for authentication or for looking up Contacts assuming that custom search paths that include the directory service have been enabled and that we have properly bound to each, most if not all of which is defined very granularly elsewhere. But suffice it to say that the plug-in architecture of Directory Services is well thought out and well laid out.
If you are interested in developing against the Directory Services API see the developer documentation here
or you can access 10.5 specific information here
krypted July 22nd, 2009
Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security
Active Directory, Centrify, defaults, directory services, DirectoryServices, dsplug, Likewise, Open Directory, plug-in, Quest, VAS
Next Page »
I originally posted this at http://www.318.com/TechJournal
If youâ€™re familiar with Managed Preferences in Tiger then youâ€™re basically already familiar with Managed Preferences in Leopard Server. But there are some great new features that Apple has provided us with by popular demand. These include the following:
There are now more features to the Applications Managed Preference. You can allow or disallow applications by selecting them individually or a folder. This means that you can allow access to applications located in the /Applications folder but disallow all applications located in the /Applications/Utilities folder. There are also now controls for allowing specific widgets and disabling Front Row.
There are new options to limit users from doing tasks when in the Finder such as Ejecting a disk, connecting to servers, rebooting and burning disks.
You can now control the list of users that are displayed to a user during login times to show Mobile accounts and network users. You can show/hide the restart button, disable automatic logon, enable Fast User switching, set the local computer record name to the name of the computer on the server, enable guest access, control the inactive time to logout users and configure computer based Access Control Lists.
Mobility now allows administrators to set an expiry for a users home folder on the system they are logging into. This allows administrators to keep local desktop systems from getting polluted with hundreds of home folders without using custom scripts to do so. Administrators can also now force accounts on local systems to use FileVault with Mobility accounts to keep data on local systems as secure as possible and set quotaâ€™s for user home directories. Finally, it is also now possible to control the path that the user home folder is located on local desktops.
Administrators can now Disable Internet Sharing, Airport and Bluetooth for client computers.
Hide profanity in the dictionary, control access to web sites, set the amount of time per day that a computer is allowed to be used and set times when login is not allowed in this new Managed Preference.
Force users to put their user name, date and/or MAC address in a page that is sent with each print job.
Allow or deny access to each System Preference (including the new ones).
krypted November 17th, 2007
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
directory services, Mac OS X Server, Managed Preferences, Mass Deployment, MCX, Open Directory