EDG System Administration

I added a user to our ldap server and then realized that I’d made a mistake. So I quickly ran an ldapmodify command to fix my mistake. Unfortunately, I had already run a finger command on the new user, which is when I saw the mistake. After the ldapmodify command, I still saw the mistake, even though I knew that it had been fixed. This problem was due to running nscd on the computer. This handles the passwd and group lookups for running programs and caches the result for the next query. The problem was that I wanted to clear the cache. The solution was to stop nscd, run the finger command which went and got the updated info and then turn nscd back on. Then all was well.

How to authenticate against and openldap server, in Apache.

Since we’re sending credentials, we want everything to be over https, so everything here is in the /etc/httpd/conf.d/ssl.conf file. I’m calling the openldap system, liberty.example.com and the system running the webserver, wishbone.example.com. The url for the site is then https://wishbone.example.com.

Right after SSL Global Context, add this line:

LDAPTrustedGlobalCert CA_BASE64 /opt/certs/ldap-server.pem

(This file is the certificate for your openldap system. It’s self-signed and a CA as well.)

Make a self-signed certificate for wishbone that you’ll use for https. If you use the Makefile, both your certificate and key will be in the same file.

SSLCertificateFile /etc/pki/tls/certs/wishbone.pem
SSLCertificateKeyFile /etc/pki/tls/certs/wishbone.pem

At the end of the file, just before the </VirtualHost>, add the following:

LDAPTrustedClientCert CERT_BASE64 /opt/certs/ldap-server.pem
LDAPTrustedMode SSL

<Directory /var/www/html>
Order allow,deny
Allow from all
</Directory>

<Location /login>
AuthType Basic
Authname 'Account Info'
AuthBasicProvider 'ldap'
AuthLDAPURL 'ldaps://liberty.example.com:636/ou=people,dc=liberty,dc=example,dc=com?uid?one'
AuthzLDAPAuthoritative off
Require valid-user
</Location>

I have a server running openldap and samba, acting like a windows domain controller. I have had no problems with adding windows 7 computers and users until today. One user could not login and this was the error.

A device attached to the system is not functioning.

Looking in the samba log file, I found this:

[2011/12/13 10:46:26.074452,  1] rpc_server/srv_pipe_hnd.c:1602(serverinfo_to_SamInfo_base)
  _netr_LogonSamLogon: user DOMAIN/user has user sid S-1-5-21-1368477355-3167354948-3261350252-4220
   but group sid S-1-5-21-3639540563-330460068-1655887120-513.
  The conflicting domain portions are not supported for NETLOGON calls

Turns out that I had some users who had the wrong sambaSID and sambaPrimaryGroupSID in their ldap account. After fixing this, the user was able to login without any problems.

Apparently, our WinXP with pGina setup doesn’t look at the SID because these users were not having any problems logging into the XP computers. It was only when moving to Windows7 that the error showed.

Edit the file /etc/ldap.conf


# Reconnect policy: hard (default) will retry connecting to
# the software with exponential backoff, soft will fail
# immediately.
#bind_policy hard
bind_policy soft


When it’s set to hard, the system looks like it’s hung (usually at Starting Udev), but it fact, it’s booting very, very slowly. If very impatient, can use a linux rescue to boot to be able to edit /etc/ldap.conf.

Started getting this error in our samba logs and no one could mount a samba drive:

failed to bind to server ldap://server.uchicago.edu with dn="cn=Manager,dc=server,dc=uchicago,dc=edu" 
Error: Server is unwilling to perform unauthenticated bind (DN with no password) disallowed

I had just installed all the updates on the server, so I’m assuming this was related. I know that I ran smbpasswd -W to put the ldap password to use to bind in secrets.tdb. So, I just ran the command again and everything was fine. I guess that one of the updates either changed the format of the file or changed the file itself. Either way, we look to be ok now.

Cronjobs for users who exist only in the ldap database were not being run. The crond log file was showing entries like this:

Dec 27 13:42:01 server crond[2781]: (arthur) ORPHAN (no passwd entry)

To fix this, make sure that nscd is running (I didn’t have it started) and restart crond.

I’m having some very strange problems with ldap and samba. Some users work fine in samba and others not at all. First, I found the /etc/pam.d/system-auth problem again, where the uid must be at least 500 for it to work. I changed that to 200 and it still doesn’t work.

I also found that each time you run authconfig-tui, /etc/pam.d/system-auth-ac gets rewritten and my 200 would go back to a 500. (system-auth is just a symlink to system-auth-ac.) I fixed this by creating system-auth-EDG and linking system-auth to that. The link does not change whenever authconfig is run, so the 200/500 uid problem looks to be solved.

But why am I running authconfig-tui so much? Because I am unable to start ldap on the server when “Use LDAP” is checked under the User Information and the Authentication sections. I uncheck them, then restart ldap successfully, then go back and recheck them. If things are checked, the ldap restart command just hangs, until I press Ctrl-C a few times. Then, it gives me errors like:

Session terminated, killing shell.......killed.
/etc/pki/tls/certs/slapd.pem is not readable by "ldap" [WARNING]
Checking configuration files for slapd: config file testing succeeded [OK]
Starting slapd:  [OK]

But it’s not really started. I have to undo the authconfig stuff, restart again (at which time it restarts in about a second) and then redo the authconfig stuff.

I’ve changed the ldap user to have a login shell and have logged in and read the slapd.pem file without a problem, so I don’t really know why it complains that it can’t be read. And since the ldap user is not in the ldap database, but it /etc/passwd, I don’t understand at all why this is a problem.

I was getting some strange errors in my maillog when an ldap user would try to call spamassassin on incoming mail. This was fixed by adding the “–ldap-config” option to the spamassassin startup script. The line in the file that I changed, no looks like this:

SPAMDOPTIONS="-d -c -m5 -H --ldap-config"

I’m slowly moving all of our users out of /etc/passwd to the ldap directory. One problem that I found was that users’ personal websites weren’t coming up. For example, user arthur, can make a directory called public_html in their home area and it would be accessible at server.uchicago.edu/~arthur. But for accounts that are only in the ldap database, it was as if these accounts didn’t exist.

To get the accounts to show, add the following to /etc/httpd/conf/httpd.conf:

< IfModule mod_ldap_userdir.c >
	LDAPUserDirServer	server.uchicago.edu
	LDAPUserDirSearchScope	subtree
	LDAPUserDirBaseDN	ou=people,dc=server,dc=uchicago,dc=edu
	LDAPUserDir		public_html
< /IfModule >

After upgrading to RHEL5 server, I had some problems where ldap would work for a while and then stop. Using this command:

ldapsearch -x -ZZ -d4

I found that it didn’t like my self-signed certificate. I have used these in the past for all sorts of things, but now, it was causing a problem. The solution was to edit the file /etc/openldap/slapd.conf and comment out the TLSCACertificateFile line.

UPDATE
I changed the group on the bundle-ca.crt file and put it back in the slapd.conf file. Things seem to work. I don’t know why this was a problem the other day.