Questions[openldap](server)

Used: openldap-servers-2.4.23-34.el6_5.1.x86_64

Task: create script for crontab to create scheduled database full backup.

1) slapcat - create file in in the default format, Berkeley DB.

2) slapcat can be done while slapd running (if bdb/hdb database used).

3) To restore file after slapcat - must be used slapadd (not ldapadd).

4) slapcat/add doesn't require password.

5) slapadd can be done only when slapd stopped.

Example:

 $ slapcat -f /etc/openldap/slapd.conf -b "dc=db_1" -l db_1_backup.ldif
 $ slapadd -l db_1_backup.ldif

Instead of slapcat/add - let's took a look at ldapsearch/add:

1) ldapsearch - creates file with almost same information as slapcat;

2) ldapadd - can use file from ldapsearch, doesn't require slapd to be stopped;

3) ldapadd/search - requires password.

Example:

 $ ldapsearch -D "cn=root,dc=db_1" -W -b "dc=db_1" "dc=db_1" -LLL > db_1_backup2.ldif
 $ ldapadd -x -D "cn=root,dc=db_1" -W -f db_1_backup2.ldif

So - question is:

1) Am I missing anything in this tools description?

2) What else is difference between ldapadd/slapadd and ladpsearch/slapcat?

During the last couple of days I have been using a lot of F-words, while browsing Internet for good documentation about how to setup an LDAP-server. So far I have found none, but plenty that are less than good, but better than bad. So I had to do it the usual Linux way, read, test, scream, read, test and scream.

My goals for the LDAP-server are:

• Install LDAP on a Centos 6 minimum installation, both for server and clients.
• Install in the way that the developers of OpenLDAP intended.
• Install LDAP securely with LDAPS, iptables, SELinux etc. enabled.
• Use SSSD on the clients for the "authentication" connections to the LDAP-server.

This is the kind of question that I usually answer myself, but I would appreciate suggestions about how to do the installation even better.

I am relatively new to LDAP, and have seen two types of examples of how to set up your structure.

One method is to have the base being: dc=example,dc=com while other examples have the base being o=Example. Continuing along, you can have a group looking like:

    dn: cn=team,ou=Group,dc=example,dc=com
    cn: team
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

... or using the "O" style:

    dn: cn=team, o=Example
    objectClass: posixGroup
    memberUid: user1
    memberUid: user2

My questions are:

1. Are there any best practices that dictate using one method over the other?
2. Is it just a matter of preference which style you use?
3. Are there any advantages to using one over the other?
4. Is one method the old style, and one the new-and-improved version?

So far, I have gone with the dc=example,dc=com style. Any advice the community could give on the matter would be greatly appreciated.

I'm setting up a wireless network for ~150 users. In short, I'm looking for a guide to set RADIUS server to authenticate WPA2 against a LDAP. On Ubuntu.

• I got a working LDAP, but as it is not in production use, it can very easily be adapted to whatever changes this project may require.
• I've been looking at FreeRADIUS, but any RADIUS server will do.
• We got a separate physical network just for WiFi, so not too many worries about security on that front.
• Our AP's are HP's low end enterprise stuff - they seem to support whatever you can think of.
• All Ubuntu Server, baby!

And the bad news:

• I now somebody less knowledgeable than me will eventually take over administration, so the setup has to be as "trivial" as possible.
• So far, our setup is based only on software from the Ubuntu repositories, with exception of our LDAP administration web application and a few small special scripts. So no "fetch package X, untar, ./configure"-things if avoidable.

UPDATE 2009-08-18:

While I found several useful resources, there is one serious obstacle:

Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.

Basically the Ubuntu version of FreeRADIUS does not support SSL (bug 183840), which makes all the secure EAP-types useless. Bummer.

But some useful documentation for anybody interested:

• http://vuksan.com/linux/dot1x/802-1x-LDAP.html
• http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius

UPDATE 2009-08-19:

I ended up compiling my own FreeRADIUS package yesterday evening - there's a really good recipe at http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (See the comments to the post for updated instructions).

I got a certificate from http://CACert.org (you should probably get a "real" cert if possible)

Then I followed the instructions at http://vuksan.com/linux/dot1x/802-1x-LDAP.html. This links to http://tldp.org/HOWTO/html_single/8021X-HOWTO/, which is a very worthwhile read if you want to know how WiFi security works.

UPDATE 2009-08-27:

After following the above guide, I've managed to get FreeRADIUS to talk to LDAP:

I've created a test user in LDAP, with the password mr2Yx36M - this gives an LDAP entry roughly of:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

When using radtest, I can connect fine:

> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
    User-Name = "msiebuhr"
    User-Password = "mr2Yx36N"
    NAS-IP-Address = 127.0.1.1
    NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
> 

But when I try through the AP, it doesn't fly - while it does confirm that it figures out the NT and LM passwords:

...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP.  Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...

It is clear that the NT and LM passwords differ from the above, yet the message [ldap] user testuser authorized to use remote access - and the user is later rejected...

This is for a small company (12 developers) who haven't implemented any centralized user database - they've grown organically and just created accounts on computers as they needed.

From a management point of view, its a nightmare - 10 computers all with different user accounts. If a user is added to one computer, they manually need to be added on all the others(that they need to access). This is far from ideal. Moving forward and growing the business will mean exponentially more work as more computers/users are added/hired.

I know that some kind of centralized user management is sorely needed. However, I'm debating between Active Directory and OpenLDAP. Two current servers function as simple backup and file-sharing servers, both running Ubuntu 8.04LTS. The computers are a mix of Windows XP and Ubuntu 9.04.

I don't have experience with Active Directory (or really OpenLDAP for that matter, but I'm comfortable with Linux), but if one solution outweighs the other then its warranted that I learn that.

Upfront cost isn't really an issue, TCO is. If Windows (SBS I'm assuming?) will save me enough time to make up for the increased upfront cost, then I think I should go with that solution.

For my needs, what solution should I be looking at implementing?

edit: Email is hosted off-site, so Exchange isn't necessary.