LDAP

[Master of Reality]

awesome i'll have to check this out on monday when im back in the school lab and after i write a midterm in this class.

[Void Main]

I also switched my squid proxy authentication over to ldap. I've been wanting to do that for a while now.

[Void Main]

This was a fun exercise:
http://directory.fedoraproject.org/wiki/Howto:SSL

[Void Main]

Alright, now I am pulling my hair out!! I was able to get SSL working on the fedora-ds installation on my local laptop yesterday but I have yet to be successful in getting it to work on the installation at home on my Myth box. I don't know what magic I did on my laptop to make it work but I just can't get it to work at home. I seem to be able to run the script to create the certificates and even get to where I think I have it configured for SSL but I'll end up with a self signed certificate error when trying to use an ldap client. I have started from scratch several times and at then end have been met with a seemingly different error each time. So close yet so far... Non-ssl directory access works perfectly.

[Void Main]

I think I figured out what a lot of my problem was. I was using the ldapsearch tool to do some test queries and editing the /etc/ldap.conf to configure how those ldap tools (and PAM) worked. I realize now that there is another ldap config file in /etc/openldap/ldap.conf that had conflicting settings. Hopefully tonight that will prove to be the answer to my frustrations. strace to the rescue again!

[Void Main]

Yep, that was it. I think I had it working before but the two different ldap.conf files threw me off. It seems /etc/openldap/ldap.conf is the configuration file for openldap (and client utilities ldapsearch, etc) and the /etc/ldap.conf is for the nss_ldap package which provides LDAP pam access, etc. I am not sure but I think you could just sym link one to the other unless you wanted different ldap settings for authentication than you would for the utilities but I am not sure why you would want that.

[Void Main]

Just talking to myself here (making notes). I'm really starting to like this Fedora Directory server. I have now mapped my passwd and group files so it's working very much like the old days when I used to use NIS on AIX, Solaris and Linux. So now if you have a Directory account you can log in to any of the servers I have connected to the directory with your LDAP ID and password. At first I imported all the IDs and groups including system IDs and groups but I decided to just keep login users and groups in the directory so the other ids/groups can be manipulated on a local level. So to summarize what I have done:

On Directory Server:

1 - Installed version 1.0.4 of the Fedora Directory Server on F7 (from FC6 RPM):

http://directory.fedoraproject.org/wiki/Download

2 - Set up FDS to use SSL by running the "first script" linked on the SSL howto page:

http://directory.fedoraproject.org/wiki ... SSL#Script

3 - Imported my user and group accounts into the directory from the /etc/passwd and group files using the LdapImport Perl utility found here:

http://directory.fedoraproject.org/wiki ... rateToLDAP

IMPORTANT NOTE 1: It's supposed to import the passwords as well but for some reason the passwords didn't make it across properly and I had to reset them in the GUI. Not a big deal at home where I only have a handful of users but if I were doing this in a production environment I would have to figure out and fix that issue.

IMPORTANT NOTE 2: When importing it will ask you where you want to put the data in your directory. It defaults to the NetscapeRoot which is not where you want the data to go. You want it to go under your user database. In my case I entered this when prompted:

ou=People,dc=voidmain, dc=home

Here is a message about it:

http://www.redhat.com/archives/fedora-d ... 00101.html

On Each Directory Client:

1 - Set up LDAP tools to use the directory by default by editing the /etc/openldap/ldap.conf to contain:

Code: Select all

BASE dc=voidmain,dc=home
URI ldaps://fds.voidmain.home/
TLS_CACERTDIR /etc/openldap/cacerts
TLS_CACERTFILE /etc/openldap/cacerts/cacert.asc
TLS_REQCERT allow


Of course change "fds.voidmain.home" and "voidmain.home" your fully qualified hostname and domain where your directory lives. Also copy the server cert /opt/fedora-ds/alias/cacert.asc to /etc/openldap/cacerts

2 - Set up your systems to authenticate against the directory by first editing /etc/ldap.conf to contain:

Code: Select all

host fds.voidmain.home
base dc=voidmain,dc=home
nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon
pam_password md5
uri ldaps://fds.voidmain.home
TLS_CACERTDIR /etc/openldap/cacerts
TLS_CACERTFILE /etc/openldap/cacerts/cacert.asc
TLS_REQCERT allow


Same thing, change fds.voidmain.home and voidmain.home to whatever your host/domain are that contain your directory.

And then add the ldap lines to your /etc/pam.d/system-auth file. Notice I added/inserted 4 pam_ldap.so lines to my F7 auth file:

Code: Select all

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        sufficient    pam_ldap.so use_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_ldap.so use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_ldap.so


3 - You want all your UID and GIDs to be the same on all machines that you want to map the passwd and group files on so if they don't match across machines there is another script called UidFixup also found at the above link that will adjust your UID/GID numbers in the passwd and group files and search the hard drive for files owned by that user and change ownership to the new ID:

http://directory.fedoraproject.org/wiki ... rateToLDAP

4 - Map your /etc/passwd, /etc/shadow and /etc/group to the directory by editing your /etc/nsswitch.conf file and adding "ldap" to your passwd, shadow, and and group lines:

Code: Select all

passwd:     files ldap
shadow:     files ldap
group:      files ldap


Now a user doesn't even have to have an account on the actual machine to log in if that machine has it's passwd, shadow, and group files mapped.

----

Things I have not yet had to deal with but are common issues:
- you'll want to make sure you don't have clashing UID and GID numbers between the directory users and the local passwd and group files.
- I'm not sure what the best method of creating a new account would be. I normally just use the "adduser" command on standalone machines. You would want a similar command that adds a user to the directory with a unique UID and GID and optionally add that to the local passwd and group files and create the home directory for the user on one or more of the machines you have participating.

What I did in the old days of NIS (YP) is to use NFS and automount. You had a master server where everyones home directory actually resided and then it would get automatically NFS mounted on any other machine they logged. That may or may not still be the best way to do it. I guess it will depend on the environment that you are setting this up in. If all the machines are configured identically and any user could use any one of them at any time that may be the best way to do it (automounted home directories).

It seems to be very flexible in that it's not all or nothing. That is you don't have to map the passwd and group files and can set up for authentication only. Or you can just use it as a regular ldap server.

The directory can obviously be used for much more than user authentication. I also pointed my Evolution address book to it and you can use it like any other LDAP database. I also am doing my squid authentication against the directory using squid_ldap_auth (included with the squid server).

I also have yet to set up a secondary server that will sync with the primary. I think that's the next thing I need to work on.

That's all for now. It almost looks like a first step to my next Fedora tip. After learning more about Fedora Directory server I might just see about implementing this at work to better manage all of our Linux, Solaris, and AIX servers. I've actually been working on setting them up with Radius authentication against our Cisco Secure ACS servers which will be backened with AD accounts for encryption capable devices and servers and two factor RSA SecurID authentication for devices not encryption capable. I think Fedora Directory Server would give us a much more manageable environment than just centralized password management.

[Void Main]

Just ran into an interesting issue. I noticed if I have "ldap" binding of "group" in /etc/nsswitch.conf the admin-serv (apache) segfaults after attempting to restart it and you can't connect to it any more. If you take the "ldap" off of "group" in /etc/nsswitch.conf it starts and works fine. I did find a message that describes the same issue from 5 years ago:

http://mail-archives.apache.org/mod_mbo ... .upc.es%3E

Not quite sure what is going on as none of the groups exist in the directory that apache runs under (I don't think). I even tried adding the nobody and root group to see if it made any difference and it didn't. Odd...

EDIT: In fact after more searching I found more messages about this happening with Apache on and LDAP/NSS client throughout the last few years and it seems to be across several platforms (including BSD, etc). Haven't seen any solution and I still don't fully understand what the exact problem is. It's not a big deal though as it seems to only happen on the Directory server itself. I wonder if I set up a replication server and point them at each other that the problem would go away...

[Void Main]

Another note to self. I was having issues getting SSL working on my home Directory server's admin console. Every time I tried to enable it I would get some sort of error about PSET something or other. I couldn't find a lot of information on that error but I ended up figuring out it was a client problem and not a server problem. I was running the Console client on my laptop and connecting to both the Directory installation on my laptop and the director installation on my myth box. I think there was some sort of clash with the certificates but wasn't obvious by the error messages. At any rate the Console client caches certain information like server certificates in the ~/.fedora-console directory. I just deleted that directory and restarted the console and then was able to configure the server for SSL and was prompted to accept it's certificate.

[Master of Reality]

I'm going to have to pour over these notes when im actually on a Fedora computer. So far i got fedora-ds and the admin console working. I havent added any users yet, only browsed around.

[Void Main]

I just set up multiple master replication between two Fedora DS servers. It was really easy:

http://directory.fedoraproject.org/wiki ... eplication

[Master of Reality]

in regards to keeping UID/GID from clashing. I was reading an article by someone using OpenLDAP and they reserved UIDs 1500-2000 for LDAP users and used 1000-1499 for local users or something to that effect.

[Void Main]

Yeah that's a good way to do it. I did it similarly in the NIS days and I also use a very high range of IDs when auto-creating local users when Samba connections are made to Linux PDF print servers I have set up. I'm sure you know this but It still can get tricky even with local users because if you use NFS you want to make sure your local users have the same UID/GIDs on any machines they have accounts on. Otherwise on one machine Fred may own data that Sally owns on another machine. Just things to keep in mind to prevent future clashes.

[Void Main]

Another possible helpful note. I noticed on the main Console there is a "Users and Groups" tab where you can search your directory. I noticed it defaulted to "o=NetscapeRoot" and that is not where my users are. They are in my own "voidmain" directory (dc=voidmain,dc=home). I thought there must be a way to change the default but I couldn't figure out how. I found this Sun documentation page which had the answer and provided a few more tips:

http://docs.sun.com/source/817-5215/usergrp.html

Basically it's as simple as clicking on the "User" menu and selecting the "Change Directory" option and replacing "o=NetscapeRoot" with "dc=voidmain,dc=home". Now I can search my users and groups from the main console page.

I also noticed Sun's Server Console is identical to Fedora Console:

Sun:


Fedora:


I guess they both came from the same place (I believe originally a Netscape project, still learning the history). So I guess Sun may also be a good source of documentation:

Sun Java(TM) System Administration Server 5 2004Q2 Administration Guide:
http://docs.sun.com/source/817-5215/

EDIT: I also found where to change the default directory. It's contained in a config file:
/opt/fedora-ds/shared/config/dbswitch.conf

[Master of Reality]

I think that it was originally the netscape directory server... which branched into OpenLDAP and Sun's server, and FDS is based on OpenLDAP.


Would you know what the o=NetscapeRoot is for? Is it used for configuration stuff or something?

I've managed to get it running, and a user added. But it doesnt authenticate my user when i try to login. This is after enabling LDAP under System > Administration > Authentication.