We backup or ldap database via slapcat. Something like: # slapcat -l `date +"%F.ldif"` That creates a file named something like 2009-06-16.ldif. Actually, what I normally do ido is this: # slapcat -l `date +"%a.ldif"` On a Tuesday, that would create a file called Tue.ldif. On Wednesday the file is called Wed.ldif. So I have a 7 day rotating backup. And then I use the same technique to create monthly archives called Jan.ldif, Feb.ldif, etc. PS: I always create certificates via cacert.org. You have to register with them and go through a process to prove that you are who you say you are. I got 2 Notaries Public to sign my papers. But you can also get other people who are already members of cacert.org to sign for you. But you have to meet face-to-face. Anyway, once you're in, you can generate certificates for free from their web site. The cacert.org root certificate is in the ca-certificates bundle so a linux machine will recognize it. Therefore, you don't have to distribute a ca cert for your self-signed cert. Other advantages of useing cacert.org are that you can use the certs for web sites, email, etc and the rest of the linux world will recognize them. Also, you don't have to worry about backing up and keeping track of your certs because if you lose them, you can download them from cacert.org again. And they're free. The drawbacks to using cacert.org are: 1. The registration process takes some work 2. IE 6 didn't have the root cert, don't know about IE 7 or IE 8 3. Certs are good for only 2 years and do not contain sufficient info about your organization to be used for e-commerce. But, if you just want to set up a server for your department or a small group, certs from cacert.org are quite sufficient. ----- Original Message ----- From: "Dave" <dave.mehler@gmail.com> To: "'Blind sysadmins list'" <blind-sysadmins@lists.hodgsonfamily.org> Sent: Tuesday, June 16, 2009 10:50 AM Subject: Re: [Blind-sysadmins] unix machine and ldap authentication
Hi, Thanks for the info on tls. I got it working, one a syntax wrong with ldapsearch on the debug, fixed that and a certificate couldn't be found. I had an extra space in a path statement, but tls is now all working, including finger and id and the like. I know what you mean about loosing the authentication database, i'm becoming paranoid about mine, backups are next. As for pam the passwd /etc/pam.d script is what i need to alter, i'll experiment around and see what works, i'll write back, this is not live yet so i don't have to worry about angry users. Do you have sudo rules in your ldap directory? Thanks. Dave.
-----Original Message----- From: blind-sysadmins-bounces@lists.hodgsonfamily.org [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of John G. Heim Sent: Tuesday, June 16, 2009 10:16 AM To: Blind sysadmins list Subject: Re: [Blind-sysadmins] unix machine and ldap authentication
The way to check if your certs work is to do an ldapsearch. On my system I do something like this:
$ ldapsearch -x -d1 -ZZ uid=jheim
Try it with the -ZZ and then without. If it works without the -ZZ, then you know you have a certificate problem. And the debug flag, -d, should show you what is wrong.
I can't directly help you with the password change script. We use a custom script because our ldap database is non-standard. I've been working for months to change the structure to conform but it's a difficult and scary process. Screw it up and I lose my authentication database.
As far as pam goes, on a debian system, you edit files in /etc/pam.d/. If you have shadow passwords enabled, you need to change at least one file, /etc/pam.d/chfn. We add this:
auth sufficient pam_ldap.so auth required pam_unix.so nullok account sufficient pam_ldap.so account required pam_unix.so session sufficient pam_ldap.so session required pam_unix.so
You may have to edit several files and try different configurations to get it to do what you want. Every time we upgrade our debian release, I have to tweak the files in /etc/pam.d/ to get everything to work. You might need to tweak files for printing, cron, ssh, etc. There's no substitute for experimentation that I know of. So if you're doing this on a live system, you're going to have trouble. I suggest you wrap your mind around the idea of working evenings and weekends. Or you can just tell your users they'll have to live with being unable to login once in a while.
----- Original Message ----- From: "Dave" <dave.mehler@gmail.com> To: "'Blind sysadmins list'" <blind-sysadmins@lists.hodgsonfamily.org> Sent: Tuesday, June 16, 2009 8:25 AM Subject: Re: [Blind-sysadmins] unix machine and ldap authentication
Hello, Thanks for your reply. I've got a directory going, that is it authenticates users. I am able to log in as an ldap user. That's the good news. The bad news is it's probably not the most efficient or secure certainly. I'm having issues getting tls going, when i uncomment tls directives i get nothing from id, finger, or logins don't happen, commenting everything out works fine. I'm using self-signed certificates. My second issue is one with passwd. I'd like it to be able to change ldap passwords in edition to passwords stored on the system. I read several items one about a patch to passwd, but can't find it or more information on it. The second is a pam configuration for passwd which looks promising. I would add: password required /usr/local/lib/pam_ldap.so to the bottom of /etc/pam.d/passwd under the unix.so module, i'm not sure if this is right i don't want to make both modules required and fail out users because they're not in both locations. Do you have this working? Thanks. Dave.
-----Original Message----- From: blind-sysadmins-bounces@lists.hodgsonfamily.org [mailto:blind-sysadmins-bounces@lists.hodgsonfamily.org] On Behalf Of John G. Heim Sent: Sunday, June 14, 2009 9:52 PM To: Blind sysadmins list Subject: Re: [Blind-sysadmins] unix machine and ldap authentication
We do ldap authentication at the University of Wisconsin Department of Mathematics. If you have specific questions let me know. But I can give you some tips on troubleshooting:
First thing you need to do is make sure you can search the ldap directory from the client machine. What you want to do is do an ldapsearch with debug on and with encryption so you can tell if your client can talk to the ldap server. On my systems I'd do something like this:
$ ldapsearch -d1 -x -ZZ uid=jheim
You will be able to tell if the client knows which server to talk to and if it can find a certificate, etc. If that works, the next thing to try is finger:
$ finger jheim
That will tell you if the client machine is configured correctly to identify logins from the ldap database. I can point you to some howtos if you get stuck at this point.
If you get past this point and logins still don't work, then you have to look in the system log on the server to see what queries are being sent from the client. And you have to check /var/log/auth.log on the client machine.
_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org http://lists.hodgsonfamily.org/mailman/listinfo/blind-sysadmins
_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org http://lists.hodgsonfamily.org/mailman/listinfo/blind-sysadmins
_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org http://lists.hodgsonfamily.org/mailman/listinfo/blind-sysadmins
_______________________________________________ Blind-sysadmins mailing list Blind-sysadmins@lists.hodgsonfamily.org http://lists.hodgsonfamily.org/mailman/listinfo/blind-sysadmins