Apr 16
Migration to OpenLDAP (Part 1 - the TODO List)
This is only a small network with a handful of users, most of them remote. But the network is a large variety of systems and services which up to now has been been managed haphazardly, with user accounts created locally on each service. Time for a change. I’d managed an NIS deployment years back but it is fraught with security holes. Since I’ve been hacking away at Solaris for a week, now is the time to give LDAP another thought.
Previously I’ve thought LDAP was too complex for it’s own good. Especially when you can create simple web based authentication schemes with a couple of SQL tables, the LDAP protocol and it’s abstract object based nature with it’s trees and schemas. Especially when /etc/passwd and /etc/groups have been my friend for so many years. Don’t get me wrong, I still think it’s a bit too pretentious for it’s own good but this time I took a step by step approach to understanding it through practical application, and multiple iterations.
I didn’t get it right the first time, and it’s still not finished. But instead of trying to get LDAP to be a silver bullet, load up on smaller caliber weapons and keep firing until you tame or kill the beast.
This is a multi-part series that goes over the iterations I’ve made and/or plan to make.
- Part One - Make the TODO list
- Part Two - Deploy OpenLDAP and migrate local accounts (Ubuntu Linux)
- Part Three - Get Linux systems migrated to LDAP (Ubuntu Linux)
- Part Four - Migrate Solaris systems
- Part Five - Migrate some web services
- Part Six - Bitchslap some security into LDAP and your network
- Part Seven - Throw it out and start again
- Part Eight - Migrate more services (what else can we do?)
Any lark who stumbles across Part Seven may gasp but this network is primarily R&D not production. Anyone planning an LDAP deployment needs to document some things and test your theories in a lab/research environment before finalising deployment to production scenarios.
TODO List
Here is what I wanted to achieve both short and long term out of this migration.
- A single login and group structure for Linux servers and desktops
- Authenticate other Unix based systems (Solaris and BSD) to the directory
- Automount home directories via NFS
- Replicate a subset of the directory to a DMZ directory for the servers on that network (also for remote/extranets)
- Harden up the LDAP deployment with some extra security layers (eg add SSL)
- Move some web services to LDAP authentication mechanisms
- Do the same for Email accounts
- Convert Samba file sharing / windows login to directory
- See what directory services can do to enhance mobile devices (roaming laptops, PDAs and mobiles, VoIP phones)
- What other services can the directory enhance (DNS?)
So far I’m stuck in the middle of this process but plan to document how I tackled each item on the list.
Before starting, I made a list of the user accounts, groups and systems that were in the initial list to be migrated. This is not a definitive list and how you migrate each will change by the time you figure out the best way to structure the directory. Get it working, then get it working right, and you will come up with some novel ways to handle you data as you proceed.
![[del.icio.us]](http://www.scriptforge.org/wp-content/plugins/bookmarkify/delicious.png)
![[Digg]](http://www.scriptforge.org/wp-content/plugins/bookmarkify/digg.png)
![[Google]](http://www.scriptforge.org/wp-content/plugins/bookmarkify/google.png)
![[Technorati]](http://www.scriptforge.org/wp-content/plugins/bookmarkify/technorati.png)
![[Yahoo!]](http://www.scriptforge.org/wp-content/plugins/bookmarkify/yahoo.png)
![[Email]](http://www.scriptforge.org/wp-content/plugins/bookmarkify/email.png)