Category Archives: Open Directory

Leveraging OpenSource and Freely Available Technology

Recently I gave a talk at the Annual TABS conference about various OpenSource technologies and how they can relate to operating more efficiently and effectively with special attention to Unix/Linux/OSX infrastructures. I think it went over very well, and I was truly surprised how little of this stuff was used by schools. Especially when everyone is focused on keeping costs down. Many schools spend their money on services and contracts for software instead on great IT people that can be innovative for education, instead they are always putting out fires. So here are the slides : TABS Slides

Integrating Open Directory and Google Apps (Natively Syncing Open Directory Passwords to Google Apps)

I have been reviewing for some time the different ways which are available to push password change updates from a Apple Open Directory (OpenLDAP) Master to our Google Apps domain, and I have waited for some time for a solution I could go with. However, I was and have been unsatisfied with the solutions which are available for OS X. I wanted a very simple, secure, and natively run solution – running on my snow leopard server or lion server. Simple is a major part here, while some people don’t mind getting into configs and changing them I wanted it to be, run a installer, answer some easy questions, and bam! So below are my personal requirements for this first round of development.

 

Integrating Google Apps with Open Directory Requirements

  1. Do NOT store a plaintext password on disk.
  2. No extra services (such as MySQL), I wanted to use a simple flat file structure, similar to svn, because it is one less thing to fail.
  3. Easily configurable, easy to extend, easy to archive, easy to remove.
  4. When a user changes their LDAP password it should change their Google Apps password.
  5. If a user sets a password on a LDAP account which does not exist in Google Apps, it should be created.
  6. It should work for multiple Google Apps Domains.
  7. Install it & forget about it.

So I wrote a simple series of bash scripts, and an easy installer & uninstaller to accomplish what I wanted. While this is my first iteration of this tool it is currently in the last stages of production deployment testing, and I believe this to be ready to be used by most. I tried reasonably well to make the setup easy and very straight forward. Everything that is needed for this to work is already on OS X Server or included in the installer.

This is designed to be installed on your ODM, while the installer is NOT fool proof – I believe it to handle the most common cases and setups without problem. I will be developing this more and maturing the features, but I am currently focusing on my own needs, so I would really like to hear what would be popular to add.

It makes heavy use of openssl for storing confidential information using public key cryptography, this also allows root to actually recover a password if the situation ever arises. The tools that are installed with this are required to be run by root as well as access to the flat file structure it uses to store information in, this is intentional so that it adds a measure of security as to who can access it. Because if someone has access to your ODM as root all bets are off anyway.

It also uses Apple’s native launchd instead of cron because of the discontinuing support of cron on Apple’s platform. I believe this is the easiest most straight forward solution I have come across for syncing passwords from OpenDirectory to Google Apps on OS X.

There are some conventions to follow in order for this to work properly and they are as follows:

  1. In each of the user accounts in OD make sure their full Google App email account is entered under the user info tab, it should be the only email address entered.
  2. In each of the Google App domains make sure you create the SAME domain admin user (the part before the @) with the SAME password.

All messages are printed to the system.log file, so watch this file if you want to see any errors or it just working. You might have to issue a -HUP or restart PasswordServer or ODM for changes to take effect, but I did not have to. Formal documentation will follow after the next release.

 

Installation is simple:

  1. Download latest zip file to Open Directory Master.
  2. Unzip file.
  3. Open Terminal
  4. Change to the setup directory inside the package (this is a must!).
  5. CD to the newly unzipped folder
  6. Run: sudo ./install.sh

googlePasswordSync Release Log:

CURRENT RELEASE: org.theObfuscated.googlePasswordSync

SPECIAL NOTE: Bugs should be filed under the issues section on GitHub at https://github.com/jjviscomi/googlePasswordSync/issues. Please include all the output from the logs and whatever else is necessary to help correct or identify the issue.

- Added Google Apps Directory Sync Integration Capability. (If you choose to it will now modify the users LDAP record to include a SHA hash of the password so that GADS can push that information to Google Apps.) However if you choose this option make sure you use DACL to prevent everyone from seeing this information.

Read more »

How to reset an Open Directory Administrator’s password

Resting a Open Directory PasswordThis is a trivial task when you are a Directory Administrator, however what if you find yourself in a situation of when your admin has left or disappeared without notice and no one else has the directory admin password … or in my case: Something really bad happened to your Open Directory Master and the directory administrator can no longer access the directory.

In the latter some might say restore from backups, but that should be an absolute last resort, and in reality backups are good for data restoration NOT system states. Well the key here is you still have to have full (root) access to the Directory Master (locally). In plain english you need to retrive the slot-id for the directory administrator and change its db password hash. I think if I have to explain it all to you then you probably shouldn’t be the one in charge to remedy this situation or you will understand by just looking how to do it. So for both cases here is a little script changeDirectoryAdminPassword.sh.

#!/bin/bash

# Author: Joseph J. Viscomi    E-Mail: jjviscomi [at] gmail [dot] com || jviscomi [at] brehm [dot] org
# Date: 2/10/2010
# Description: This script is interactive, it prompts you for a new password. It
#              will get the slot-id for the given user and attempt to change it's
#              password. This needs to be run using sudo.

if [ $# = 1 ]; then
  echo "Going to change password for $1"
  echo -n "slot id: "
  echo `sudo mkpassdb -dump | grep $1 | awk '{ print $3 }'`
  sudo mkpassdb -setpassword `sudo mkpassdb -dump | grep $1 | awk '{ print $3 }'`
fi

The above script takes exactly one argument, the short name of the directory administrator.  If you follow the manual when creating your Open Directory Master it is labeled as diradmin (which should be changed …) so this command would be run like the following:

sudo ./changeDirectoryAdminPassword.sh diradmin

Simply follow it if you want to know what it is doing, line 13 is where the magic happens! I have never actually run this script so their might be a typo or something. If there is a problem let me know and I will correct it, but it looks good. I hope no one ever needs to deal with this.

Better workaround when unable to authenticate to WGM in OS X

I oversee a large OpenLDAP / OpenDirectory network, and when implementing Apple’s OpenDirectory into the mix we came across some very stage errors and bugs. When dealing with OpenDirectory we found that it was not well documented and the fixes to a lot of our problems were to demote and promote or reboot. Both of these fail to explain why and introduce down time into the system, this was un acceptable. So one of our biggest pains was the authentication to the directory was not working via WGM or when attempting to do an authenticated bind. However when a restart was preformed (as was recommend by Apple) everything starting working correctly again. This seem to occur randomly with out any real concrete event causing it, after extensive review of our logs.

With further inspection I was able to craft a simple bash script which flushed out & restarted the services that were having the problems. This prevented downtime and was simple enough to schedule via launchd on our servers or to simple run it when needed. Now this is NOT a fix but a better work around then restarting the entire server or the ridiculous demote and promote of the server (If someone suggests this then they have no idea what they are talking about, you might as well as do a full reinstall).

Below the flushodm.sh script can be easily run to restore most normal server operations.

#!/bin/bash

# Author: Joseph J. Viscomi    E-Mail: jjviscomi [at] gmail [dot] com || jviscomi [at] brehm [dot] org
# Date: 3/23/2011
# Description: This script can be used to flush the state of OpenDirectory Service without
#              restarting the server. This should be run as root or using sudo.

# KILLS Directory Service Process - It will automatically restart.
dscacheutil -flushcache
kill -9 `ps ax | grep DirectoryService | grep -v grep | awk '{ print $1 }'`

# KILLS Password Service - It will automatically restart.
dscacheutil -flushcache
kill -9 `ps ax | grep /usr/sbin/PasswordService | grep -v grep | awk '{ print $1 }'`

# FLUSHES mDNSResponder
dscacheutil -flushcache
kill -HUP `ps ax | grep /usr/sbin/mDNSResponder | grep -v grep | awk '{ print $1}'`
dscacheutil -flushcache

#FORCE REPLICATION - JUST FOR GOOD MEASURE
slapconfig -replicatenow
Performance Optimization WordPress Plugins by W3 EDGE