Tech Stuff - Samba PDC + LDAP

This page is now dreadfully out of date but may still provide some useful background. One day when we have nothing useful to do we may update it. It is, after all, only number 273 on our todo list.

This page is available in Czech language (translated by Alex Novak from bizow.com). Many thanks.

We decided to replace an aging NT4.0 PDC with a FreeBSD + Samba + LDAP solution to support our mixed Windows, Linux, FreeBSD network. The implementation we used was:

1. Samba 3.0.6

2. FreeBSD 4.10

3. OpenLDAP 2.2.15

We try and point out differences for our less fortunate Linux brothers and sisters - just joking! This HOWTO addresses the pain of configuring LDAP and Samba. If you need help in setting up samba this is not the place for you.

Contents

1. Overview and Background
2. NT LAN Manager
3. LDAP Structure
4. Setup and LDAP Population
5. Files and Samples
6. smb.conf LDAP parameters
7. OpenLDAP Guide

Overview and Background

Our ultimate goal is single sign-on for administrative convenience rather than any lofty goals. FreeBSD 4.10 gives us a temporary problem because it does not support system logon via LDAP. This means we have to replicate those users who require access system resources in both the LDAP and via add_user. If you are a Linux or FreeBSD 5.x user this is not a problem. In spite of this we continued because:

1. The actual number of users that require access to system resources is low in comparison to the total number of users - we keep non-system users for email, FTP and web access in the same LDAP structure (see this table).

2. FreeBSD 5.x does support LDAP logon via NSS services - so when we finally migrate to 5.x we just need to stop manual synchronization - like stopping banging your head off the wall we expect it will be quite pleasant when that happens.

3. We have decided that a directory based core architecture is the fundamentally 'right thing™' for the future - so any temporary difficulty is just a bump-in-the-road to the future (impressive or what)!.

So we installed Samba as a PDC with non-LDAP authentication and got it all running as a test system just to prove the PDC configuration. We have subsequently seen this suggested in Samba documentation and consider it profoundly wise advice. Don't start with an LDAP implementation unless you have done it all before or you have a high threshold of pain.

Now we came to add LDAP to the configuration and the problems and questions started - and in fact constiture the primary motivation for writing this HOWTO. What do all the Samba objectclasses do? do we need them all? how do we configure LDAP to use them? We had used and configured Samba many times before and had never even seen the terms SID and RID - just what are they and more important WHY do we have to know about them?

It is vital to understand that the consequence of selecting an LDAP implementation is that you are necessarily exposed to all this SID/RID junk - and a number of other things besides - simply because the configuration of LDAP (the authentication database) is not under the control of Samba code - whereas with tdbsam authentication the Samba code controls its authentication database and consequentially does lots of automagical things - which has the up-side of making you think you are smarter than you are. In an LDAP implementation you - the ace sys admin - need to do all the work that is defaulted in tdbsam - which has the down-side of reminding you of just how dumb you really are!

You can frankly save yourself a lot of agony by not using LDAP. We decided that the other advantages of LDAP (common datasource blah, blah, blah, etc.) were worth the pain. Or rather we would undergo the pain once and as a consequence of the extreme trauma it would be erased form our memory (bit like child-birth - or so we are reliably told). Or maybe we are just into pain!

Some Tips

We get confused very easily - here are some things we think are very important to remember or in some cases to forget:

1. If you know LDAP better than Samba don't even look at the Samba schema until you are well into the implementation - we got blind-sided (it happens frequently) by trying to figure what and where all the objectclasses had to be defined - in some cases Samba automagically uses them. Reverse engineering from the schema is a Bad Thing™.

2. If you have NO existing LDAP system then you could do no worse than just blindly follow the IDEALX Samba Howto which really is the best document out there on Samba PDC plus LDAP. IOHO however they assume you either know lots or are prepared to take lots for granted. In our perpetual search for truth and knowledge we fell into neither category (is that pompous or what). Alternatively you can assume (probably more correctly) we are just too dumb to follow instructions!

3. If you have an existing LDAP system and are merging Samba LDAP authentication then you have to understand a bit more - but take the time 'cos if you don't using some of the tools will get you into serious trouble.

4. Start by understanding and defining the Samba LDAP smb.conf parameters and then figure out what you have to do to OpenLDAP. Note: On the subject of smb.conf parameters we found a number of references to the non-robust validation of parameters by samba - when we looked at the code to get the exact format of a couple of parameters we found this to be not quite true. With trivial exceptions there is NO PARAMETER VALIDATION. You can easily get a non-viable Samba configuration by getting a couple of smb.conf parameters wrong - we now consider ourselves now amongst the worlds experts in this form of Samba configuration - non-viable configurations that is! So if Samba is not working when you initially load it forget the friendly log files and look carefully at your parameters.

NT LAN Manager NTLM)

We found that we had to know more about LAN manager than we had ever desired to know - or rather to understand the process of configuring Samba we kept stumbling upon terms and concepts that we had the vague suspicion we only half understood - we were generally correct in our suspicion - we only half understood them! We have collected together a background page which we call a Survivors Guide to NTLM. We also reference this page as necessary from the text below to provide additional detail.

LDAP Structure

Samba LDAP needs you to define 5 key parameters (all LDAP parameters) and structure your LDAP hierarchy accordingly:

1. Where in the LDAP hierarchy the NTLM user accounts are stored - using the ldap user suffix parameter. Each NTLM user account must map to a UNIX (POSIX) account on the PDC. Defned using the AUX objectclass sambaSamAccount.

2. Where in the LDAP hierarchy the NTLM groups are stored - using the ldap group suffix parameter. Each group - which may be built-in or user defined - must map to a UNIX (POSIX) group on the PDC.

3. Where in the LDAP hierarchy the NTLM machine accounts are stored - using the ldap machine suffix parameter.

4. Optional Where in the LDAP hierarchy the NTLM group mapping information is stored - using the ldap idmap suffix parameter.

5. Kinda Optional A user and password using the ldap admin dn parameter. This can be the normal rootdn parameter of OpenLDAP - this however has the disadvantage that Samba can write to EVERY location in your LDAP DIT - if ever Samba decided to go a little wild you could have a few problems. It is much wiser and recommended that you define a separate user in the DIT which has permissions to modify, add and read only Samba specific fields (the downside is you need to define an access to clause). Life is never easy.

LDAP DIT

How you define this stuff will depend on whether you have an existing LDAP directory or not and if you do have an existing implementation what data (objectclasses) it currently contains. Lets look at three cases:

No existing LDAP implementation

This is the simplest state - follow the IDEALX Samba PDC Howto slavishly. They know what they are doing. You are going to build an LDAP system that is tailored to Samba so DIT structure can be optimized for this purpose.

Existing LDAP - Directory Information Only

If you are using an existing directory implementation e.g. based on, say, person or inetOrgPerson and it does not contain security information to control access to system resources e.g. system logon - but you may be using it for authentication for email, LDAP access, ftp access etc. then you must make some choices. By default Samba uses the uid attributes (controlled by ldap filter parameter).

Existing LDAP - Security Information

Setup and LDAP Population

Files and Samples

---

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.