krypted.com

Tiny Deathstars of Foulness

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. Screen Shot 2015-01-16 at 11.22.15 PM When prompted to destroy the LDAP Master, click on Next. Screen Shot 2014-12-15 at 10.09.56 PM When asked if you’re sure, click Continue. Screen Shot 2014-12-15 at 10.10.00 PM When asked if you’re really, really sure, click Destroy. Screen Shot 2014-12-15 at 10.10.03 PM Wait.

January 19th, 2015

Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , ,

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. 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.

odr5

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.

October 16th, 2014

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , ,

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. Screen Shot 2014-06-10 at 8.41.54 AM   Hope you enjoy!

June 10th, 2014

Posted In: Articles and Books, Mac OS X, Mac OS X Server

Tags: , , , , , ,

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. Screen Shot 2013-10-08 at 10.28.11 PM Towards the bottom of the screen, click on the cog wheel icon. At the menu, click Archive Open Directory Master… Screen Shot 2013-10-08 at 10.28.23 PMWhen prompted, provide the username and password to the Open Directory environment shown in the Server field and then click on the Connect button. Screen Shot 2013-10-08 at 10.29.03 PMAt 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. Screen Shot 2013-10-08 at 10.29.06 PM 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. Screen Shot 2013-10-08 at 10.28.11 PM Here, click Promote Replica to Master. Screen Shot 2013-10-08 at 10.29.37 PMAt 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. Screen Shot 2013-10-08 at 10.29.57 PMClick 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”. Screen Shot 2013-10-08 at 10.30.00 PMThe server is then stopped. To completely remove Open Directory from the server, run the slapconfig command, followed by -destroyldapserver: slapconfig -destroyldapserver Also, don’t forget to go to the Master and remove any servers from there as well, once they’ve been fully demoted.

October 22nd, 2013

Posted In: Mac OS X Server

Tags: , , , , , , , , , , , ,

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. Test Access 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? Profiles 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.

April 3rd, 2012

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , ,

opendirectoryd 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: killall 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. dsconfigldap 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’?!?!). Kerberos 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: ktutil list dsconfigad 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. Defaults 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… 🙂

July 20th, 2011

Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , , , , , , ,

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.

January 22nd, 2010

Posted In: Active Directory, Mac OS X Server

Tags: , , , ,

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.

July 22nd, 2009

Posted In: Active Directory, Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , , , , , ,

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: Applications 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. Finder 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. Login 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 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. Network Administrators can now Disable Internet Sharing, Airport and Bluetooth for client computers. Parental Controls 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. Printing Force users to put their user name, date and/or MAC address in a page that is sent with each print job. System Preferences Allow or deny access to each System Preference (including the new ones).

November 17th, 2007

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , ,

Kerberos uses keys to transmit information between hosts.  There are  session keys and service keys kept in the keytab file on the KDC.  The KDC (Key Distribution Center) then does out keys as needed.  To see the service keys: klist -k /etc/krb5.keytab

September 28th, 2007

Posted In: Mac OS X Server

Tags: , , , , , , , ,

Next Page »