Open Directory Crashing from Wildcard SSL Certificate

Posted: March 14th, 2015 | Author: | Filed under: LDAP, Mac OS X Server, SSL | No Comments »

I encountered an issue recently where I imported a wildcard certificate into an Open Directory server which was fine however once I tried to select it Open Directory immediately stopped working.


2015-03-14 10:42:07.113 AM com.apple.launchd[1]: (org.openldap.slapd[20606]) Exited with code: 1
2015-03-14 10:42:07.113 AM com.apple.launchd[1]: (org.openldap.slapd) Throttling respawn: Will start in 10 seconds
2015-03-14 10:42:17.150 AM com.apple.launchd[1]: (org.openldap.slapd[20612]) Exited with code: 1
2015-03-14 10:42:17.150 AM com.apple.launchd[1]: (org.openldap.slapd) Throttling respawn: Will start in 10 seconds

To diagnose I turned ldap off by way of launchd

sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

And then told openldap to launch in debug mode and don’t fork.

sudo /usr/libexec/slapd -d 99 -F /etc/openldap/slapd.d/

To which I received this reply:

TLS: attempting to read `/etc/certificates/server.inside.tld.ca.6C66FD3E997A9FD902DEA9050EE3F9A58EF63742.key.pem'.
TLS: could not use key file `/etc/certificates/server.inside.tld.ca.6C66FD3E997A9FD902DEA9050EE3F9A58EF63742.key.pem'.
TLS: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch /SourceCache/OpenSSL098/OpenSSL098-47.2/src/crypto/x509/x509_cmp.c:406
55047382 main: TLS init def ctx failed: -1

That’s strange I thought, so I cracked open /etc/openldap/slapd.d/cn=config.ldif in vim and found that at the bottom of the file the cert and the key did not change over properly.

olcTLSCertificateKeyFile: /etc/certificates/server.inside.tld.ca.6C66FD3E997A9F
D902DEA9050EE3F9A58EF63742.key.pem
olcTLSCertificatePassphrase: "Mac OS X Server certificate management.6C66FD3E9
97A9FD902DEA9050EE3F9A58EF63742"
olcTLSCertificateFile: /etc/certificates/*.inside.tld.ca.8597F1FABB98A20805065
751BA49E3076EF84E60.cert.pem
olcTLSCACertificateFile: /etc/certificates/*.inside.tld.ca.8597F1FABB98A208050
65751BA49E3076EF84E60.chain.pem

Notice how the certkeyfile does not match the cert or chain file? It’s like Server.app b0rk3d on parse the wildcard symbol while modifying this file. The only way I’ve figured out how to get OD back on it’s feet after this disaster is to remove these lines from the cn=config.ldif and rebooting the OD server. Even if I tried hand coding the cert in Open Directory will stop crashing however the secure LDAP service does not come up.

I’ve since switched to an internal CA and making certs for each FQDN which has been a way better experience.


Open Directory Replication 10.8.5 problems with Kerio Connnect 8.3.0

Posted: June 22nd, 2014 | Author: | Filed under: Kerberos, Kerio, LDAP, Mac OS X, Mac OS X Server, Mountain Lion, Open Directory | Tags: , , , , | No Comments »

kms_bubbleI recently was hired to implement an Open Directory Master/Replica into a network that wanted to leverage Kerio Connect mail server. At first, all seemed fine. I created the directory, the replica, and installed the kerio extension on both servers as was instructed by the fine folks at Kerio. Now I’d just like to say that this is different than what I remember in the days of 10.6. Back then you only had to install the OD extension on the master, the replica would then copy the schema over so that it could import the extended schema data at that time.

The problem comes into play when you have a master with already provisioned users in Kerio and you want to add an OD replica. Since the replica does not copy over the extended LDAP schema it is unable to replicate any provisioned users. The result is that those users will not exist in the replica which is bad news if you have services relying on that replica. To resolve this problem use the following procedure on the replica you wish to build:

sudo slapconfig -createreplica <master IP> diradmin

Once complete install the Kerio extention.

slapconfig -stopldapserver
slapadd -v -F /etc/openldap/slapd.d -c -l /var/db/openldap/openldap-data/backup.ldif
slapconfig -startldapserver

#gowellandinpiece
#replication


Enable VNC for Zentyal Community Server

Posted: February 27th, 2013 | Author: | Filed under: Blog, DNS, Kerberos, krb5, LDAP, Linux, Networking, Work, Zentyal | 4 Comments »

Get a terminal session on your Zentyal box and install the VNC service

sudo apt-get install vnc4server

Next, run the server once to initialize a config file, kill the service and make a backup of the config file and then edit.


vncserver
vncserver -kill :1
cp .vnc/xstartup .vnc/xstartup.bak
nano .vnc/xstartup

Uncomment one line and add another:


# Uncomment the following two lines for normal desktop:
unset SESSION_MANAGER
# exec /etc/X11/xinit/xinitrc
/usr/bin/lxsession -s LXDE -e LXDE

Then just launch
vncserver

Watch the output so you can ensure what port to connect to. For example, the following means my VNC server is listening on port 5901


jordan@mrsparkle:/etc/X11$ vncserver

New 'mrsparkle:1 (jordan)' desktop is mrsparkle:1

Starting applications specified in /home/jordan/.vnc/xstartup
Log file is /home/jordan/.vnc/mrsparkle:1.log


Apache LDAP Authentication, Require ldap-group, OpenLDAP server, AND YOU!

Posted: March 20th, 2011 | Author: | Filed under: LDAP, Linux | Tags: , , , , , | 1 Comment »

OK peoples, this one frustrated me for a bit, but because I’m stubborn I figured it out.

I have a webservice that I want to protect by using LDAP authentication within Apache from our OpenLDAP server. However, you want to make sure that the user belongs to a specific LDAP group. If you’re like me your groups look something like this:

bart:~ jordan$ ldapsearch -h ldap.shop.lan -x -b "dc=shop,dc=lan" cn=fgstaff
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: cn=fgstaff
# requesting: ALL
#

# fgstaff, Groups, shop.lan
dn: cn=fgstaff,ou=Groups,dc=shop,dc=lan
cn: fgstaff
gidNumber: 1022
description: Staff
objectClass: posixGroup

memberUid: jordan

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

So to make it work you need a few things inside of your Directory tag for the virtual host config file. First, here’s mine:


Options FollowSymLinks
AllowOverride None
AuthName "FG Staff ONLY!"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthLDAPURL "ldap://1.1.1.1/ou=People,dc=shop,dc=lan?uid"
require ldap-group cn=fgstaff,ou=Groups,dc=shop,dc=lan
AuthLDAPGroupAttributeIsDN off
AuthLDAPGroupAttribute memberUid

The trick for me was putting in the require ldap-group plus the whole path including container, org unit, and the dc’s. Then AuthLDAPGroupAttributeIsDN. This is big because if it is on then apache will check if “memberUid=uid=jordan ou=People” is part of the fgstaff group and not just “jordan”

Once I set this, it all worked. I’m hoping this will help any others out there.


Apple Magic Triangle Deployment Results

Posted: October 15th, 2010 | Author: | Filed under: Active Directory, DNS, Kerberos, LDAP, Mac OS X Server, Migrate, Snow Leopard | Tags: , , , , , , , | No Comments »

This is a follow up to my last blog entry: Magic Triangle Setup with Windows File Server backed Portable Home Directories. Myself and a team of amazing people deployed the Magic Triangle solution in an architectural firm that recently was involved in a merger and needed to be brought into one unified “domain.” I place that word in quotations after some disagreements and long discussions with AD administrators as to the default definition of the word. Before we begin let’s just go over our Magic Triangle deployment and the roles of our servers.

  • vandc01.tld.ca is the local AD domain controller.
  • vanfile.tld.ca is the Windows based file server for all network home directories
  • od01.tld.ca is the Open Directory server which was also bound to AD
  • od02.tld.ca is the OD replica and netboot server for Deploy Studio
  • For all intensive purposes, the migration went fairly smoothly. The client was quite happy with the result, although the users of the network do not have as fast of a desktop environment as they did with a pure Macintosh network. The final outcome was Mac clients bound to both AD and OD. AD handled all the user and group authentication and authorization while OD took care of computer and group client management through MCX. I put a standard computer heirarchy in place on the OD side for computer group so different settings could be applied to different sets of computers. Such as, making all laptops automatically create portable home directories and install the HomeSync menu in the top menu bar. However, there was one very strange problem I encountered while binding the Macintosh clients to the Open Directory server.

    Normally, when you set “Require authenticated binding between directory and clients” to on in Server Admin the Mac client will prompt you for directory administrator credentials when binding a client. However, this was not happening for us. We were using 10.6.4 server and client everywhere, yet the clients were just not asking for authentication. Thus, a computer record was not being generated on the server side. What I did for the first few test cases was create computer records manually inside of Workgroup Manager, but this was not fun and tedious.

    Update: One of my readers, JJ, pointed out a great kb article from Apple on how to require directory authentication while binding. http://support.apple.com/kb/HT4068 End of Update

    I whipped up a quick AppleScript to bind the clients for me, this script had the diradmin login and pass embedded in it which I know is not best practice yet it was a temporary fix. The reason for using the script is so that the command line utility dsconfigldap is passed the ‘-f’ flag which forces the client to authenticate to the directory server.

    The script is as follows:


    tell application "Terminal"
    do shell script "dsconfigldap -u diradmin -p 'diradminpass' -f -a od01.tld.ca -c `hostname` -n od01.tld.ca -l localsudouser -q localsudopass -v > /Users/Shared/odbind.log" with administrator privileges
    do shell script "echo 'Writing Search policy to plists' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/SearchNodeConfig 'Search Node Custom Path Array' -array '/LDAPv3/od01.tld.ca'" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/SearchNodeConfig 'Search Policy' -int 3" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/ContactsNodeConfig 'Search Node Custom Path Array' -array '/LDAPv3/od01.tld.ca'" with administrator privileges
    do shell script "defaults write /Library/Preferences/DirectoryService/ContactsNodeConfig 'Search Policy' -int 3" with administrator privileges
    do shell script "echo 'Successfully added the Open Directory server to your search path' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "echo 'Writing LDAP in your search paths' >> /Users/Shared/odbind.log" with administrator privileges
    do shell script "dscl /Search -append / CSPSearchPath /LDAPv3/od01.tld.ca" with administrator privileges
    do shell script "dscl /Search/Contacts -append / CSPSearchPath /LDAPv3/od01.tld.ca" with administrator privileges
    end tell
    tell application "Finder"
    activate
    display dialog "Computer is now bound to Open Directory as " & (do shell script "hostname")
    end tell

    File Migration from Apple Filer to Windows Filer

    This was one of the more challenging issues at hand. We had a whole bunch of OD user’s home folders on two Apple XRAIDs served out via AFP and needed to move the data to the Windows Filer using SMB. What we ended up doing is creating an LACP link to a MacPro and using the following script to migrate the users one by one.

    syncit.sh is a shell script that mounts two network homes for one user, one from AD and one from OD. It then transfers all data from OD to AD via rsync. To make this script work it depends on a couple things.

  • The users to be migrated are entered into a file called ‘users’ with NO extension in the following format
    1. oduser:aduser
      oduser:aduser
      oduser:aduser
      oduser:aduser
      oduser:aduser
  • When the script executes it will create the folder /Users/Shared/syncit_logs and two log files for each user. username.log username.err. The .log is all the stdout of rsync while .err is all the errors.
  • And finally when you download the script you’ll need to edit the variables at the top of the script with the FQDN’s for you file servers and shares.

    You can get the script here.

    Caveats

    Home Directory Ghost Mount
    One issue that we’ve seen appear more than once is home directory ghost mounting. When a user logs out of their profile sometimes their home directory does not unmount cleanly. As a result when the user tries to log in again on the same workstation they are unable to due to the computer believing the home directory is already mounted. This may also affect logins of the same user account to other workstations due to the home directory filer not timing out the mount session.

    Slow Network File System Access
    There have been at times severe client stalls due to slow file system access. This was noticed on literally zero network traffic congestion. This is a noted issue from many different implementations of using SMB shares for Mac home directories. Read http://www.macwindows.com/snowleopard-filesharing.html#091709k for more information. One suggested solution is to turn on Internet Sharing on the Mac client, however this is not a wise idea.

    Portable Home Directory Will Not Sync
    Sometimes homesync will become cranky. Definitely cranky. The easier and fastest way to resolve a home directory that does not sync is to perform the following.

  • Erase the contents of the users’s ~/.FileSync and ~/Library/FileSync directories.
  • Manually mount the user’s network home directory and erase the same directories on the server
  • Try the sync process again. Note: It will take longer to catalog the file system.
  • For most HomeSync problems it usually has something to do with file conflict resolution. To find out always open Console.app and look at FileSyncAgent.log. Try to perform a FileSync and watch the output of the log. If you are having problems with an initial sync try erasing the login.keychain file found in ~/Library/KeyChains on both server and client. Many times this will cause problems due to The Chicken and The Egg issues.

    Illegal Characters in File Names
    “ ‘/ \ + * ( ) [ ] are all illegal characters for file names on the Windows File Servers, as are directories or files that end in a space. As a result you may have issues creating working with these files. The Windows file server use unicode to map these characters, however there are failures often. Resolution is done by manually replacing filenames. This is also a LARGE contributor to File Sync failing.

    Summary

    Like I mentioned at the beginning everything went quite smoothly. There were of course strange things that happened through out the deployment, and the short one week runway I had to prep for this was WAY too short but in the end we pulled it off. If any of you out there are planning on deployment or need questions answer feel free to contact me via the About Me button at the top of blog!

    Update: Please check out my next post regarding HomeSync errors on an SMB server.

    Update 2: One of my readers, JJ, pointed out a great kb article from Apple on how to require directory authentication while binding. http://support.apple.com/kb/HT4068


    Snow Leopard Server and Linux client using LDAP and libpam-krb5

    Posted: May 24th, 2010 | Author: | Filed under: Kerberos, krb5, LDAP, Linux, Mac OS X Server, Snow Leopard | 1 Comment »

    This is an extension article to my previous article Open Directory, Kerberos, Single Sign On (SSO) and CentOS with SSH and Kerberized NFS Home Directories. I had some requests from different Linux users out there how to incorporate authentication for Linux flavours other than CentOS. For this example we’re going to use Debian Lenny with some Ubuntu 10.04 refs thrown in.

    Preperation – LDAP

    First download all the packages that we’ll need.
    Debian
    apt-get install nss_updatedb ldap-utils libpam-ldap libnss-ldap nscd
    Ubuntu
    apt-get install nss_updatedb ldap-utils libpam-ldap libnss-ldap nscd nslcd
    During the installation debconf should ask you some questions, here are my answers

    LDAP server Uniform Resource Identifier: ldap:/// (Note the "ldap://", NOT "ldapi://"!)
    Distinguished name of the search base: dc=foo,dc=bar
    LDAP version to use: 3
    Does the LDAP database require login? No
    Special LDAP privileges for root? No
    Make the configuration file readable/writeable by its owner only? No
    Make local root Database admin. No
    Does the LDAP database require login? No
    Local crypt to use when changing passwords. crypt

    If you’re not on Debian you can edit these options in the file /etc/ldap/ldap.conf and /etc/libnss-ldap.conf

    Next, edit /etc/nsswitch.conf and change

    passwd: compat
    groups: compat

    --to--

    passwd: files ldap
    groups: files ldap

    Now restart the nscd service ( and nslcd if you’re using Ubuntu 10.04 )

    Verify you can see the users via LDAP with the id or getent commands

    jordan@elm:/$ id jordan
    uid=1000(jordan) gid=100(users) groups=1001(ldap-admin),1022(fgstaff),1023(ssh-access),100(users)


    jordan@elm:/$ getent passwd | grep jordan
    jordan:x:1000:100:Jordan Eunson:/net/home/jordan:/bin/bash
    jordan@elm:/$

    Preperation – libpam-krb5

    Download and install the packages
    apt-get install krb5-config libpam-krb5

    Then edit your /etc/krb5.conf file. Now here what you *could* do is copy the one from you Mac. If you have a Mac client already bound to your Open Directory installation then open the file /Library/Preferences/edu.mit.Kerberos and copy and paste the content to /etc/krb5.conf

    Here is an example of mine for the realm FOO.BAR

    [libdefaults]
    default_realm = FOO.BAR
    [realms]
    FOO.BAR = {
    admin_server = od-master.foo.bar
    kdc = od-master.foo.bar
    }
    [domain_realm]
    .foo.bar = FOO.BAR
    foo.bar = FOO.BAR
    [logging]
    admin_server = FILE:/var/log/krb5kdc/kadmin.log
    kdc = FILE:/var/log/krb5kdc/kdc.log

    To test to see if this is working type the command kinit and see if we can get a ticket from the Kerberos Key Distribution Center


    bart:~ jordan$ kinit jeunson
    Please enter the password for jeunson@FOO.BAR:
    bart:~ jordan$ klist
    Kerberos 5 ticket cache: 'API:Initial default ccache'
    Default principal: jeunson@FOO.BAR

    Valid Starting Expires Service Principal
    05/24/10 16:30:35 05/25/10 02:29:14 krbtgt/FOO.BAR@FOO.BAR
    renew until 05/31/10 16:30:35

    bart:~ jordan$

    Kerberos Authentication

    Now that we have our Kerberos client working we can integrate the local system to LDAP for user lookup and Kerberos for passwords with PAM libraries.

    /etc/pam.d/common-account

    account sufficient pam_unix.so
    account required pam_krb5.so

    /etc/pam.d/common-auth

    auth sufficient pam_unix.so nullok_secure
    auth sufficient pam_krb5.so use_first_pass
    auth required pam_deny.so

    /etc/pam.d/common-session

    session required pam_unix.so
    #session required pam_mkhomedir.so skel=/etc/skel/ umask=0022
    session optional pam_krb5.so minimum_uid=1000

    Now try to login to your Linux client either on the console to see if it works. To finish up with Kerberizing the client please read this article


    Free Geek Server Room Build Part 4 AKA How I learned to love LTSP, Migrate OpenLDAP and get bind running all in one day!!

    Posted: May 8th, 2010 | Author: | Filed under: DNS, Free Geek, Insight, LDAP, Linux, Migrate, SSH, Vancouver | 2 Comments »

    Free Geek Mascot #1

    Today was awesome! We got so much done!!! And it all went without a problem… oh except for when we tried to create an LACP bond on our NFS server and crashed the whole network… yeah… Quick story on that. we have 10 VLANs all trunking between our switches and our router. The NFS server is on VLAN 5 untagged on port 17 on the switch, we the added port 18 and created a bond on the switch. We then created a bond0 interface on the NFS server and used ifenslave to assign the eth devices to the bond device. Then….

    BAM! WHOLE NETWORK GOES DOWN. Not just vlan5, no no, the whole god damn network. No Internet access nothing, not even from the router, the router can’t ping a thing on the whole network.

    Why God? Why?

    Then the Network God ARP said, “Jordan did you check those top kwality DLink switches?” So off I went to check the switch I just modified. For some unknown reason the DLINK decided to plunk VLAN 6 tagged onto port 16 for no reason what-so-ever. So I fixed that, but no, nothing worked still. So Tyler says, just unplugg the ethernet cables to the NFS server. Voila! Problem solved. Basically we think the NFS was just spewing out crap across the network and making all the servers in VLAN 5 bail, including the router. We were getting some pretty crazy ARP poisoning happening the router. Now, on to the good stuff.


    This is a basic (and poorly made) diagram of how the Free Geek Vancouver network looks. We’ll take a look at how an LTSP client boots and logs in.

    First the LTSP client boots looking for a PXE server, DHCP is handed out and tells the client to grab a boot image from yew. The LTSP client then boots into Ubuntu 10.04 (bleeding edge baby) where the login screen is presented. The user logs in and authenticates against our new fancy LDAP server on teak. When the client logs in their home directory is handed out via LDAP as /net/home/<$user> This directory is handled by AutoFS and mounts the NFS home from maple. The user now has full desktop experience with all their account info and home directory handled by 3rd parties.

    What? Centralized authentication AND home directories?! REALLY?

    Our LTSP server is now a 2 x Dual Core Xeon 3.20GHz with 4GB of RAM. A HUGE upgrade from what we running before. In addition to all this insanity Vicki was able to migrate our ticketing system for us as well as update all the LDAP records for home directories, install autofs on all servers, install the mount maps, comment out all the irrelevant fstab crap AND switch over all our servers to the LDAP server. Pow vicki, pow!

    The backup system is pretty sweet as well. In our NFS server that holds the home directories is two RAID 5’s, a RAID 1 and some spares. One RAID 5 has a slice out of it that is for home directories. The other is 1TB for nothing but backups. What Tyler did was write a script that uses rsync to create incremental backups all done thru hard links. It’s pretty rad.

    Now that I come to think of it, I didn’t really do much except play with the dogs!!

    She helped in her own way


    What's going on?

















    Free Geek Server Rack Build PART THREE!!!!

    Posted: May 4th, 2010 | Author: | Filed under: Free Geek, LDAP, Linux, SSH | 2 Comments »

    Yes, yes, I know. Two months have gone by since the last entry about Free Geek. Well finally I had some time to make it down there and to my enjoyment though Tyler from Free Geek had been busy at work. He managed to do quite a bit of work while I was away. Here’s a pic and some highlights!

    Front of Rack

  • 6 port KVM
  • 16 Bay SATA disk pool server
  • The UPS has been racked
  • Gigabit backbone switches are in place
  • All the servers have been wired in the back
  • All running Ubuntu Server 10.04 LTS
  • Fancy fancy LCD and keyboard tray (ooooh aaaaaah)
  • Complete radicalness! (FTW!)
  • All the HP iLO’s have been configured
  • AND color coded ethernet cabling! (BAM!)
  • NFS storage raid with lots of space and redundancy (BAM! BAM!)
  • Enough hardware to run two Free Geeks!
  • And some Tyler secret tricks!
  • Now first I must mention something that happened which was spectacular. I showed up to Free Geek with tools in hand ready to kick ass and chew bubblegum. I said ‘Hi’ to the gang and then got right to work going over what’s been done already and what we should do for the day. Then I heard a small voice coming from behind me. It all started with a simple ‘Hello.’ Tyler and I turned around and here stood this lady, she said that she had heard we were doing updates to the network and wondered if she could help. I have something to confess here, I judged at first sight. So my initial response was ….. uhhhhhh….. and in my head I was thinking “oh god I have SO much to do today, I can’t possibly teach and babysit someone else.” However we said ok you can help

    “what’s your name?” I asked

    “Vicki” she replied.

    I said “OK, Vicki, I’m going to outline on this whiteboard what we hope to accomplish today.”

    Damn! That's nice wiring!

    I then began drawing out network topologies and what VLAN’s we were going to roll out that day. Tyler pulls up a network diagram I had done up briefly a few weeks ago to talk about subnet allocation and service assignments. All the while Vicki was quietly watching and listening. We then went about which of our new servers would be responsible of what task, such as “teak” was going to be our new LDAP and DNS server, maple the new NFS server, how authentication was going to happen for autoFS mounts and so on. Granted if you’ve been in this industry for a while this isn’t super complex stuff, LDAP migration, network topology planning, thinking ahead for future departments, etc etc. However, this isn’t childs play either, let’s be honest there are a lot of ‘sys admins’ out there and not all of them could roll out a network of this size.

    We turned to Vicki and started going thru the tasks on the board, expecting (I was anyway) to see a lot of confusion. BUT NO! OMG! She knew just as much, if not MORE about this stuff than we did. In fact, over lunch we got into a discussion about proper use of VLAN’s and subnet routing between them. This woman was (is) AMAZING! It was like the network God looked down from heaven and with his noodley appendage, blessed our tech mecca for that day by sending us a worker! A worker that new how to install services, write config files, test connectivity and map VLAN’s!!! Quite literally she cut our work time by 40% if not more. If anyone needs a good sysadmin, or network engineer who knows their way around a linux terminal and learns by being shown ONCE! Contact me, I’ll send her details on to you.

    Anywho, Tyler and I laid out the VLAN’s and what they would be responsible for. We had configured three switches thus far to trunk all the VID’s but when we got to the fourth and final switch, we had no admin credentials for it. (My fault!) Our plan at that point was to wait until the end of the day, reset the switch, recover the password and then move our core router to the rack. In the meantime I checked up on Vicki and she had gotten all of our services, OpenLDAP, bind, Zenoss, apt-cache, TFTP server, and some other stuff up and running and was ready for configuration. I migrated the database from an older version of OpenLDAP with a slapd.conf file to the new version with the slapd.d directory.

    Tyler and Vicki (Respectively)

    Once the Free Geek came to an end Tyler and I moved the router from the bathroom server room to the upstairs rack, pushed the ADSL modem thru and VLAN, and then made an LACP trunk to our OpenBSD router. Put the VLAN interfaces in place and POW. Network configured. (For the most part) The final stage is migrating the servers to the proper VLAN’s and updating their services configurations.

    The next and final post will be mostly diagram based. Stay Tuned! HOPEFULLY the next post will be really insightful IF I can get Luke and Kamil from Zymeworks to donate some time into rebuilding our Asterisk server and implementing a KDC


    Using Network Accounts on a Linux Client with Open Directory Leopard Server

    Posted: December 1st, 2009 | Author: | Filed under: LDAP, Linux, Mac OS X Server, Snow Leopard | 2 Comments »

    I have two linux machines at home and I want to be able to use my network home directory and network account from my Leopard Open Directory server. One is running Ubuntu 9.10 and the other OpenSuSE 11.2. Here’s what I had to do:

    In this post I assume you already have an Open Directory environment and network based user accounts as well as AFP homes setup. In other words, a working Open Directory setup with bound AND working Mac clients.

    Exporting User Home Directories with NFS

    First we want to make sure that the home directories are being exported via NFS. Open Server Admin and connect to your OD master. At the top of Server Admin click on File Sharing and then your AFP home folder volume. Click on File Sharing up at the top and select your AFP home volume. The click on the “Share Point” button in the bottom pane and then “Protocol Options” (Note: if “Enable Automount” is not checked you either have the wrong volume selected or your configuration is incorrect)

    In the Protocol Options drop down select the NFS tab and select a means by which to export the NFS share. I would recommend using subnet and if you know what you’re doing select a minimum security of “Kerberos v5 with data integrity and privacy” however you should only select this if you REALLY know what you’re doing. I will make a walk through for this at a later date. If you don’t know Kerberos like the back of your hand then I would select “Any” for now. Check Allow Subdirectory Mounting. Click OK and you’re done.

    Ubuntu 9.10 Authentication

    On the Ubuntu Linux client first install the necessary packages:

    sudo apt-get install libpam-ldap libnss-ldap nss-updatedb libnss-db nfs-common nscd

    In the following wizard just accept the default answers, they should be correct. Then edit /etc/ldap.conf and make it sure it contains the following lines. Note this is not a verbatim output of /etc/ldap.conf


    host 192.168.1.1
    # this should be the IP of your OD server or better yet service based CNAME record
    base dc=example,dc=com # this is of course the ldap search base configured in the OD server
    bind_policy soft

    Now edit /etc/ldap/ldap.conf

    BASE dc=example,dc=com
    URI ldap://example.com

    /etc/pam.d/common-account

    account sufficient pam_ldap.so
    account required pam_unix.so

    /etc/pam.d/common-auth

    auth sufficient pam_ldap.so
    auth required pam_unix.so nullok_secure use_first_pass

    /etc/pam.d/common-password

    password sufficient pam_ldap.so
    password required pam_unix.so nullok obscure min=4 max=8 md5

    /etc/pam.d/common-session

    session required pam_unix.so
    session required pam_mkhomedir.so skel=/etc/skel/
    session optional pam_ldap.so

    /etc/nsswitch.conf

    passwd: files ldap

    group: files ldap

    shadow: files ldap

    hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
    networks: files

    protocols: db files
    services: db files
    ethers: db files
    rpc: db files

    openSuSE 11.2 Authentication

    On the command line start yast

    Navigate to Network Services and then LDAP client type in your LDAP server IP and search domain, unclick TLS and bam you’re done. God I love Novell 😉

    Ubuntu 9.10 & openSuSE 11.2 Automount

    Create the directory /Network/Servers then all that is needed is to create the following line in /etc/auto.master

    /Network/Servers /etc/auto.net

    Restart autofs

    sudo /etc/init.d/autofs restart

    After this you should be able to log in and access your home folder.


    How-To OpenLDAP, Quick n’ Dirty Edition

    Posted: October 20th, 2009 | Author: | Filed under: LDAP | No Comments »

    Install Ubuntu Server Edition 8.10, boot it up and install OpenLDAP.


    sudo apt-get install slapd ldap-utils

    You can probably just accept the defaults if this is just for testing, therefore your domain will be dc=example,dc=com. In the install wizard it should ask you to setup your ldap admin user this user’s dn should be cn=admin,dc=example,dc=com

    Then you’ll need to add two organizational units, one for People, one for Groups. Create the file myldap.ldif and place into it this:


    dn: ou=people,dc=example,dc=com
    objectClass: organizationalUnit
    ou: people

    dn: ou=groups,dc=example,dc=com
    objectClass: organizationalUnit
    ou: groups

    If LDAP is running, shut it down with /etc/init.d/slapd stop

    Use ldapadd to add the ldif file to our LDAP database: ldapadd -x -D cn=admin,dc=example,dc=com -W -f myldap.ldif It will ask you for your password that you set during the install.

    Fire LDAP back up /etc/init.d/slapd start and then install webmin:

    sudo aptitude install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl libmd5-perl
    wget http://garr.dl.sourceforge.net/sourceforge/webadmin/webmin_1.441_all.deb
    sudo dpkg -i webmin_1.441_all.deb

    You can now navigate to your LDAP server’s IP at port 10000 https://your-server-ip:10000/. Note you will be required to enter the root password for the computer at this login screen.

    From here we need to configure webmin to interact with our LDAP environment. Expand “System” and then select “LDAP Users and Groups.” Click “Module Config” at the top of the page and find the following option and enter this custom data:

    Base for users ou=People,dc=example,dc=com
    Base for groups ou=Groups,dc=example,dc=com

    Click save at the bottom. You will be returned to the previous screen where you can now add LDAP users and groups. This is now a functioning LDAP server. You can query it from the command using ldapsearch

    Whole database: ldapsearch -x -h -b "dc=example,dc=com"
    User search: ldapsearch -x -h -b "dc=example,dc=com" '(uid=blah)'