RHEL4 authentication to Windows 2003 Active Directory
Linux - EnterpriseThis forum is for all items relating to using Linux in the Enterprise.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
1. will the command "openssl x509 -inform DER -in activedirectory.crt -outform PEM -out adcert.pem" give me the same output as "openssl pkcs7 -in activedirectory.cer -inform DER -out adcert.pem -outform PEM" because the second one horks on my systems, with a cannot load PKCS7 object error. I believe it should work fine, since the goal is turn the cert into PEM form.
2. the fact that the nsswitch.conf example is on a gentoo box kind of throws me, is that the same content needed for a fedora system? I assume so, but I've been wrong before on how different linux distros handle the same thing.
3. The /etc/pam.d/system-auth file says it is auto generated there in the text. So does it need to be edited, or is that the result I should get from the other steps?
I'll probably have a few more questions before I finish ironing out all the issues.
I can not remember for sure how I took my Windows cert and included in /etc/openldap/certs directory. Seems like it was more like what you were doing in your first example.
The /etc/nsswitch.conf file is similar on CentOS 4 distro which would be very similar to a fedora based distro.
You can hand edit /etc/pam.d/system-auth file, but if you use one of the fancy fedora/red-hat tools (system-config-authentication, authconfig, or other tool) for modifying the files then your hand edits will be lost.
kerberos auth is utterly trivial, I have a keytab, can do ldapsearches no prob, etc. As an example, if I simply use: ldapsearch "msSFU30Name=brianl"
I get my entire record! No worries!
Problem is, nss_ldap won't resolve uids/gids. I put debug on all the pam lines, and set the debug line in /etc/ldap.conf to 1. The stuff it shows me that I worry about is (Uid nums changed..."XXXX" is actually a valid, correct number):
Clearly it's just...something...in /etc/ldap.conf, but I've used every suggested permutation of /etc/ldap.conf (the 3 suggested in this thread were tried, for example) to no avail.
What bothers me is if instead of ldapsearch "msSFU30Name=brianl" I use ldapsearch "msSFU30Name=brianl" "objectclass=User" I no longer get my whole record...instead, I just get my DN as below. Could that be all that nss_ldap is getting back to, and thus has nothing to map back to my uid/gid? Remember, if I leave off the objectclass=user and just search my name, I get my full record...not just the below.
Fedora Core 6 doesn't authenticate on a W2k3 R2 Server via Ldap
I tried to use the configuration shown for a test of a Fedora core 6 and a Windows 2003 R2 Domain but I have not been able to make it work. I removed the Certificate part to not complicate the things while I cannot make it work.
Every time that I try to authenticate I have the following error:
[root@ldaptestclient ~]# su raul
su: user raul does not exist
[root@ldaptestclient ~]# su ldap_test
su: user ldap_test does not exist
and in the /var/log/secure I have the following errors:
[root@ldaptestclient ~]# tail /var/log/secure
May 3 11:34:37 ldaptestclient sshd: nss_ldap: reconnecting to LDAP server (sleeping 16 seconds)...
May 3 11:34:46 ldaptestclient sshd: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)...
May 3 11:34:53 ldaptestclient sshd: nss_ldap: reconnecting to LDAP server (sleeping 32 seconds)...
May 3 11:35:18 ldaptestclient sshd: nss_ldap: reconnecting to LDAP server (sleeping 64 seconds)...
May 3 11:35:25 ldaptestclient sshd: nss_ldap: reconnecting to LDAP server (sleeping 64 seconds)...
May 3 11:36:22 ldaptestclient sshd: nss_ldap: could not search LDAP server - Server is unavailable
May 3 11:36:29 ldaptestclient sshd: nss_ldap: could not search LDAP server - Server is unavailable
May 3 14:19:12 ldaptestclient gdm: pam_unix(gdm:auth): check pass; user unknown
May 3 14:19:12 ldaptestclient gdm: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
May 3 14:21:16 ldaptestclient gdm: pam_succeed_if(gdm:auth): error retrieving information about user raul
Attached is my /etc/ldap.conf and the /etc/nsswitch.conf
# This file should be world readable but not world writable.
# Active Directory Mappings
nss_map_objectclass posixAccount User
nss_map_objectclass shadowAccount User
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute cn sAMAccountName
nss_map_attribute uniqueMember member
nss_map_attribute userPassword msSFU30Password
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_objectclass posixGroup Group.com
[root@ldaptestclient ~]# vi /etc/nsswitch.conf
passwd: files ldap compat
shadow: files ldap compat
group: files ldap compat
hosts: files dns
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
I'm sure that it is something easy but too hard for a newbie in this topic.
Mambley, It has been a very long time since I have looked at this stuff, and I do not have my test environment available, but it looks like your LDAP config is set up for Microsoft's Service for Unix (SFU). You mention you are using Win2k3 R2 which does not require the Services for Unix package. It instead has its own schema updates and utilities.
See some of the links posted in early messages of this thread. There are examples between Win2k3 R2 and Win2k/2k3 with Services for Unix.
I did not strictly analyze your config, but from a high level your ldap.conf file did not appear to match that of someone utilizing Win2k3 R2 features.