The original instructions are found here. Note, however, that this post contains all the information from the original post plus a few added points found during the latest run through the steps.
Assumptions
This procedure assumes that you are using Windows Server 2003 R2; if you are using a previous version, the LDAP attribute mapping will need to be modified to match the schema extensions found in Microsoft’s Services for Unix (SfU) add-on product. This will require changes to the “ldapclient manual†command shown below, which handles the schema/attribute mapping.
Preparing Active Directory (One-Time)
These steps only need to be performed once. Note that if you have performed any of these steps as part of authenticating Linux or Solaris to Active Directory, they do not need to be performed again. Simply make note of the information used earlier and re-use that information again this time.
- Install the “Server for NIS†component on at least one Active Directory domain controller (DC), so that the Active Directory schema can be extended to become partially RFC 2307-compliant. Installing this component will also add a “UNIX Attributes†tab to objects inside the Active Directory Users and Computers MMC console. You may also need to install the Server for NIS administrative tools on your workstation to see the “UNIX Attributes†tab.
- Use the Schema Management MMC snap-in to index the uid attribute, which is not indexed by default. This will speed up the login process and reduce the overall load on your DCs. (For more information, refer to the Linux-Windows Server 2003 R2 integration instructions.) It may be possible to change the attribute that Solaris is looking for, but I haven’t found a way to do that yet.
- Create an account in Active Directory that will be used to bind to Active Directory for LDAP queries. This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine. I recommend giving this account a simple, short name; this will make specifying the DN of the account later easier to do.
- Create a global security group in Active Directory Users & Computers and set the UNIX attributes for this group.
Once these one-time steps have been completed, we can proceed to configuring the individual users that will be authenticating to Active Directory from your Solaris server(s).
Preparing Active Directory (Each User)
Each Active Directory account that will authenticate via Solaris must be configured with a uid and other UNIX attributes. This is accomplished via the new “UNIX Attributes†tab on the properties dialog box of a user account (this tab was made visible by the installation of the Server for NIS component). The attributes that must be populated are:
- NIS domain: It’s required on this tab in order to populate the other fields, but we won’t be using it.
- UID: This is actually the UID number. Each user must have a unique UID; I believe that the Server for NIS defaults at a starting UID of 10000, which is pretty safe for most systems.
- GID: In addition, each member must have a GID (group ID); simply specify the group that was created earlier.
- Login Shell: Specify a login shell (such as “usr/bin/csh†or “/sbin/shâ€) for each user.
- Home Directory: Specify the home directory (such as “/export/home/sloweâ€) that will be used for this user. Keep in mind that these values may apply across multiple systems and platforms, and the path must be valid on all systems and platforms.
Based on my experience so far, the values for Solaris will often be very different than what might be specified for Linux-based logins. I haven’t yet figured out how to reconcile these differences in a multi-platform environment (suggestions are welcome).
After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Solaris server(s) that will enable the authentication.
Preparing Active Directory (Each Solaris Server)
These steps need to be repeated for each Solaris server that will authenticating via Kerberos to Active Directory.
- Create a user account (not a computer account) for each Solaris server. (Review this article for more information on the reasoning behind this approach.) I highly suggest using a naming convention that supports a) the service principal(s) involved; and b) the name of the server. Since Solaris will use the host service principal, a name like “host-solarissrvr†would be good. The password doesn’t matter, but do be sure to check the “Password never expires†check box, and after the account is created specify a good description so that you’ll remember what this account is for in 6 months.
- For each account that was created, run the ktpass.exe command to generate a unique keytab for each account. The command will look something like this (substitute the appropriate values where necessary):
ktpass -princ host/fqdn@REALM -mapuser DOMAIN\account -crypto DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_PRINCIPAL -out filename
Be sure to specify a unique output filename (so that you don’t overwrite files; each server/account will needs its own unique file). I suggest using the server’s name as the filename, i.e., something like “solarissrvr.keytabâ€.
Now that each Solaris server has a matching account in Active Directory, and each account has had a keytab generated for it, we’re almost ready to move on to configuring the Solaris servers themselves. First, though, we need to take care of some name resolution issues.
Configuring Reverse DNS
On the DNS server handling the reverse lookup zones for the subnet on which the Solaris server is located, add a PTR record for the Solaris server and it’s IP address. This will ensure that reverse DNS lookups work as expected. Make sure that each Solaris server that will be authenticating against Active Directory has a reverse lookup record in DNS.
Configuring Solaris (Each Server)
The following steps need to be performed on each Solaris server that will authenticate against Active Directory.
Configuring the hosts file
To enable reliable TGT validation (this ensures that the Kerberos ticket returned by a KDC actually came from the KDC and not a spoofed server), you’ll need to edit the hosts file. On Solaris 10, this is found in /etc/inet/hosts and is read-only, even for root. Edit this file (changing permissions as necessary) so that the line with the server’s IP address looks something like this:
10.1.1.1 hostname.example.com hostname loghost
What we’re doing here is making sure that the server’s fully qualified domain name (not just the short hostname) is the first name entry on the line for the server’s IP address.
There may or may not be other entries in the file; leave those entries untouched (unless you know you need to modify them).
Configuring Kerberos
Solaris keeps its Kerberos configuration in the /etc/krb5 directory as krb5.conf. Edit this file using your editor of choice to look something like the one below. Depending upon how you configured Solaris during the installation, some of this configuration may already be present.
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = true
[realms]
EXAMPLE.COM = {
kdc = dc01.example.com
kdc = dc02.example.com
admin_server = dc01.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
.subdomain.example.com = EXAMPLE.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
version = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
You can’t simply copy and paste from here to the Solaris configuration file, as you’ll need to customize your version for your particular network, hostnames, domain names, etc.
Transfer the keytab generated earlier by the ktpass.exe utility (in our example, it was called “solarissrvr.keytabâ€) to the Solaris server in some secure fashion, like SFTP or SCP. Place it in the /etc/krb5 directory as krb5.keytab, and make sure that only root has permissions to the file.
Configuring LDAP
We’ll use the native Solaris “ldapclient†utility to configure the LDAP support in Solaris. The command you’ll type in looks something like this (please don’t copy and paste this, as it contains generic/incorrect information that won’t work!):
ldapclient manual \ -a credentialLevel=proxy \ -a authenticationMethod=simple \ -a proxyDN=cn=proxyuser,cn=Users,dc=example,dc=com \ -a proxyPassword=Password1 \ -a defaultSearchBase=dc=example,dc=com \ -a domainName=example.com \ -a “defaultServerList=172.16.1.10†\ -a attributeMap=group:userpassword=userPassword \ -a attributeMap=group:memberuid=memberUid \ -a attributeMap=group:gidnumber=gidNumber \ -a attributeMap=passwd:gecos=cn \ -a attributeMap=passwd:gidnumber=gidNumber \ -a attributeMap=passwd:uidnumber=uidNumber \ -a attributeMap=passwd:homedirectory=unixHomeDirectory \ -a attributeMap=passwd:loginshell=loginShell \ -a attributeMap=shadow:shadowflag=shadowFlag \ -a attributeMap=shadow:userpassword=userPassword \ -a objectClassMap=group:posixGroup=group \ -a objectClassMap=passwd:posixAccount=user \ -a objectClassMap=shadow:shadowAccount=user \ -a serviceSearchDescriptor=passwd:dc=example,dc=com?sub \ -a serviceSearchDescriptor=group:dc=example,dc=com?sub
The easiest way to handle this would probably be to copy it into a blank text file, edit it to include the specific details for your network, and then paste it into a terminal session on the Solaris server.
After this command has been run, Solaris will create the LDAP configuration in /var/ldap and will update /etc/nsswitch.conf to use LDAP. However, because we only want to use LDAP for specific purposes, we’ll need to go back and edit /etc/nsswitch.conf again. Just remove “ldap†from all entries in /etc/nsswitch.conf except for passwd and group.
While you’re editing /etc/nsswitch.conf, be sure to add a “dns†entry at the end of the line for hosts:
hosts files dns
This will help ensure that Solaris is properly configured to use DNS for host name resolution.
I think it’s necessary at this point to restart the LDAP client service:
svcadm restart svc:/network/ldap/client:default
Use the “svcs -a | grep ldap†command to verify the exact name of the LDAP client service on your Solaris server.
Configuring the DNS Client
You’ll also need to make sure that the DNS client is enabled and running. Using “svcs -a | grep dns†will help you identify the correct service, which you can then enable with svcadm:
svcadm enable svc:/network/dns/client:default
Test DNS resolution using either the “host†or “nslookup†commands.
Configuring PAM
The /etc/pam.conf file controls the PAM (Pluggable Authentication Mechanism) configuration on Solaris. You’ll need to edit the /etc/pam.conf file to look something like what’s shown below. I’ve edited away all the non-essential sections, so only change the sections listed below.
# Default definition for Authentication management # other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_cred.so.1 other auth required pam_unix_auth.so.1 # # Default definition for Account management # other account requisite pam_roles.so.1 other account sufficient pam_unix_account.so.1 other account required pam_ldap.so.1 #
With this configuration in place, Solaris will use Kerberos authentication and will retrieve account information via LDAP.
Reboot the Solaris Server
I know this sounds stupid, but even after restarting LDAP and enabling/starting/restarting the DNS client, things still didn’t work for me in the lab. However, after rebooting the Solaris server, it worked like a champ. So, just in case, reboot the Solaris server after completing the configuration.
Testing the Configuration
Once all of the configuration steps have been completed, you can test the configuration with the following commands:
- You can use “getent passwd <Name of AD user>†from the Solaris server; this command should return UID number, GID number, UNIX home directory, and login shell.
- You can use “kinit <Name of AD user>†to test Kerberos authentication. A succesful Kerberos test will not return any feedback, and the “klist†command will show a ticket granting ticket (TGT) from the Active Directory DC/KDC.
If either of these tests are unsuccessful, review the log files on the Solaris server and resolve the problems before continuing. Both of these tests will need to be successful in order for authentication to work correctly.
If the tests are successful, then you should now be able to authenticate on a Solaris server using your Active Directory username and password. I tested this using SSH and the X Desktop login.
Tags: ActiveDirectory, Interoperability, Kerberos, LDAP, Solaris, UNIX
-
about Rob’s previous post
Tuesday, April 22, 2008 at 5:43 am
Rob
The setup which works fine in our infrastructure is as follows:This by having the following entries in /etc/nsswitch.conf :
passwd: files ldap
group: files ldap
netgroup: ldap3) we manage “netgroups”, one netgroup per server, to restrict access to people from teams that we expect to have to perform work on that server :
at the end of /etc/passwd, add the 2 lines
+@netgrpnameforthisserver:x:::::
-:x:::::I thought we have to use passwd_compat in order to enforce
netgroup access, and that was confirmed by Sun support :nsswitch.conf :
passwd: files compat
passwd_compat: ldapmy problem is that as soon as I enable that config, It stops working
and I get this error message from nscd :Aug 11 15:20:48 machine nscd[3644]: [ID 293258 user.warning] libsldap: Status: 7 Mesg: LDAP ERROR (12): Unavailable critical extension.
I continue looking around
-
Question, we’ve got this ALMOST working. Except, when we login after everything is setup it dies. Password is accepted according to the logs, but it doesn’t appear the kerb communication finishes and it dies.
Steps:
1. SSH to box:
2. Enter password (ldap pass)
3. Authenticates succesfully. Shell drops connection (connection closed).The Fix:
1. Set verify_ap_req_nofail=false.
2. SSH to box:
3. Enter password (ldap pass)
4. Authenticates succesfully and lets me in.My kerb key’s look approriate….any ideas?
Logs with ap_req_nofail=true enabled:
Sep 4 16:05:46 hostname sshd[696]: [ID 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=0
Sep 4 16:05:46 hostname sshd[696]: [ID 549540 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: start: user=’tclauj01′
Sep 4 16:05:46 hostname sshd[696]: [ID 704353 auth.debug] PAM-KRB5 (auth): Forwardable tickets requested
Sep 4 16:05:46 hostname sshd[696]: [ID 912857 auth.debug] PAM-KRB5 (auth): Renewable tickets requested
Sep 4 16:05:46 hostname sshd[696]: [ID 179272 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: krb5_get_init_creds_password returns: SUCCESSLogs with ap_req_nofail=false:
Sep 4 16:13:19 hostname sshd[747]: [ID 655841 auth.debug] PAM-KRB5 (auth): pam_sm_authenticate flags=0
Sep 4 16:13:19 hostname sshd[747]: [ID 549540 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: start: user=’username’
Sep 4 16:13:19 hostname sshd[747]: [ID 704353 auth.debug] PAM-KRB5 (auth): Forwardable tickets requested
Sep 4 16:13:19 hostname sshd[747]: [ID 912857 auth.debug] PAM-KRB5 (auth): Renewable tickets requested
Sep 4 16:13:19 hostname sshd[747]: [ID 179272 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth: krb5_get_init_creds_password returns: SUCCESS
Sep 4 16:13:19 hostname sshd[747]: [ID 833335 auth.debug] PAM-KRB5 (auth): attempt_krb5_auth returning 0
Sep 4 16:13:19 hostname sshd[747]: [ID 914654 auth.debug] PAM-KRB5 (auth): pam_sm_auth finalize ccname env, result =0, env =’KRB5CCNAME=FILE:/tmp/krb5cc_1000′, ag
e = 0, status = 0
Sep 4 16:13:19 hostname sshd[747]: [ID 525286 auth.debug] PAM-KRB5 (auth): end: Success
Sep 4 16:13:19 hostname sshd[747]: [ID 699746 auth.debug] PAM-KRB5 (acct): debug=1, nowarn=0
Sep 4 16:13:19 hostname sshd[747]: [ID 531709 auth.debug] PAM-KRB5 (acct): no module data for KRB5_AUTOMIGRATE_DATA
Sep 4 16:13:19 hostname sshd[747]: [ID 712548 auth.debug] PAM-KRB5 (acct): exp_warn start: user = ‘username’
Sep 4 16:13:19 hostname sshd[747]: [ID 734734 auth.debug] PAM-KRB5 (acct): fetch_princ_entry: non-RPCSEC_GSS chpw server, can’t get princ entry
Sep 4 16:13:19 hostname sshd[747]: [ID 615945 auth.debug] PAM-KRB5 (acct): exp_warn: fetch_pr failed 4
Sep 4 16:13:19 hostname sshd[747]: [ID 748222 auth.debug] PAM-KRB5 (acct): exp_warn end: err = 4
Sep 4 16:13:19 hostname sshd[747]: [ID 712902 auth.debug] PAM-KRB5 (acct): end: Success
Sep 4 16:13:19 hostname sshd[747]: [ID 629253 auth.debug] PAM-KRB5 (setcred): start: nowarn = 0, flags = 0×1
Sep 4 16:13:19 hostname sshd[747]: [ID 586274 auth.debug] PAM-KRB5 (setcred): kmd auth_status: Success
Sep 4 16:13:19 hostname sshd[747]: [ID 735350 auth.debug] PAM-KRB5 (setcred): end: Success
Sep 4 16:13:19 hostname sshd[747]: [ID 800047 auth.info] Accepted keyboard-interactive for username from 0.0.0.0 port 4372 ssh2
~ -
Any idea how to map a AD group as a secondary group UNIX LDAP Client
-
Hi Scott,
Excelent BLOG.
For those which the commands kinit and getent works but have this error message when try to log using an AD user:
PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found
there is a workaround adding this line in krb5.conf under section libdefaults:
verify_ap_req_nofail = false
For me the reason of this problem was because I replaced in the ktpass commad line the word “host” by the hostname (lester in my case).
This works for me now:
ktpass -princ host/lester.dominioprueba.local@DOMINIOPRUEBA.LOCAL -mapuser DOMINIOPRUEBA\server-sun-lester -crypto DES-CBC-MD5 +DesOnly -pass MyPassword -ptype KRB5_NT_PRINCIPAL -out krb5.keyfile.lester
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=”Servidor SUN Lester”,cn=Users,dc=dominioprueba,dc=local \
-a proxyPassword=Cientec123 \
-a defaultSearchBase=dc=dominioprueba,dc=local \
-a domainName=dominioprueba.local \
-a defaultServerList=191.1.20.209 \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=cn \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=dominioprueba,dc=local?sub \
-a serviceSearchDescriptor=group:dc=dominioprueba,dc=local?subBe aware with the owner of the krb5.keyfile, it showl be owned by user root and group sys.
I hope this will be usefull for anyone..
Sorry for my english… no es muy bueno. -
Hi Scott,
thank you for the great info in you main article.
Was wondering if you have come across the following problem:MS SBS 2008 as AD server, Solaris 10 as client,
All seems to be working ok, user creation etc…
But we get huge amounts of the following error in /var/adm/messages:May 8 14:24:30 higgs last message repeated 11 times
May 8 14:33:54 higgs nscd[210]: [ID 545954 user.error] libsldap: makeConnection: failed to open connection using sasl/GSSAPI to ForestDnsZones.twice2much.local
May 8 14:33:55 higgs last message repeated 11 timesAny ideas?
Dirk
-
this string incorrect
-a proxyDN=cn=proxyuser,cn=Users,dc=example,dc=com
correct string
-a proxyDN=cn=proxyuser,ou=Users,dc=example,dc=com -
Nope, sorry–last time I looked, the Users container was not an organizational unit and therefore you couldn’t use “ou=Users”. The original string is correct.
-
I would like to use SRV records in DNS for the Unix box to locate the Kerberos server.
Has any one got this working? I have tried hacking a few things in to the krb.conf & krb5.conf files without luck so far but keep trying. I know that MS does this inside their DNS inside AD, so I know it is possible, I am just looking for the client configuration to use DNS (instead of a hard-coded FQDN). If the client can not reach that FQDN for any reason, no auth’ can take place.
Thx !
-
Jason,
Some versions of the Kerberos libraries—and I don’t know if Solaris has this functionality or not—have functionality that tell it to use DNS to locate the KDC. If I recall correctly, the dns_lookup_kdc directive is what you are seeking. I know I’ve used that on Linux, but I don’t know if it’s supported on Solaris.
Good luck!
-
Should this same LDAP configuration work against Active Directory 2008? I’m only interested in the LDAP side of things for now, not Kerberos.
When I run either:
getent passwd posixuser1
getent group posixgroup1I don’t see any result returned. Logs (/var/adm/messages) say:
Feb 12 13:50:25 sunidmtest02.qut.edu.au getent[7301]: [ID 293258 user.warning] libsldap: Status: 91 Mesg: openConnection: simple bind failed – Can’t connect to the LDAP server
The strange thing is. I can see the successful bind with a packet dump on the domain controller. I can see the POSIX information is sent back to the ldapclient on the Solaris 10 server. There are no errors in the Event Logs on the domain controller. It’s like the ldapclient is not getting complete information needed to report the passwd/group entry or is not functioning correctly. I can’t see why the Solaris ldapclient reports a failed bind.
Here’s my ldapclient config:
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= CN=solaris,CN=Users,DC=pgs,DC=its,DC=tils,DC=qut,DC=edu,DC=au
NS_LDAP_BINDPASSWD= {NS1}4aeb363ad07c60169e3e
NS_LDAP_SERVERS= 131.181.78.24
NS_LDAP_SEARCH_BASEDN= dc=pgs,dc=its,dc=tils,dc=qut,dc=edu,dc=au
NS_LDAP_AUTH= simple
NS_LDAP_SEARCH_SCOPE= sub
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:dc=pgs,dc=its,dc=tils,dc=qut,dc=edu,dc=au?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:dc=pgs,dc=its,dc=tils,dc=qut,dc=edu,dc=au?sub
NS_LDAP_SERVICE_SEARCH_DESC= shadow:dc=pgs,dc=its,dc=tils,dc=qut,dc=edu,dc=au?sub
NS_LDAP_ATTRIBUTEMAP= group:userpassword=userPassword
NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid
NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:uid=sAMAccountName
NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory
NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn
NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=loginShell
NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=shadowFlag
NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=userPassword
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group
NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=userHas anyone else got this working with AD2008?
-
Digging a bit further. When i try a simple ldaplist. E.g.:
—snip—
ldaplist -lv passwd
+++ database=passwd
+++ filter=(&(objectclass=posixaccount)(uid=posixuser1))
+++ template for merging SSD filter=(&(%s)(uid=posixuser1))
ldaplist: LDAP error (openConnection: simple bind failed – Can’t connect to the LDAP server)
—snip—/var/adm/messages shows:
—snip—
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 453631 user.debug] tid= 1: Adding connection (serverAddr=131.181.78.24)
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 776464 user.debug] tid= 1: Initialized sessionPool
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 816976 user.debug] tid= 1: Connection added [0]
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 467101 user.debug] tid= 1: connectionID=1024
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 805042 user.debug] tid= 1: shared=1
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 982078 user.debug] tid= 1: usedBit=0
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 727660 user.debug] tid= 1: threadID=1
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 577507 user.debug] tid= 1: serverAddr=131.181.78.24
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 939703 user.debug] tid= 1: AuthType=1
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 142272 user.debug] tid= 1: TlsType=0
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 537450 user.debug] tid= 1: SaslMech=0
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 625532 user.debug] tid= 1: SaslOpt=0
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 639905 user.debug] tid= 1: userID=CN=solaris,CN=Users,DC=pgs,DC=its,DC=tils,DC=qut,DC=edu,DC=au
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 293258 user.warning] libsldap: Status: 91 Mesg: openConnection: simple bind failed – Can’t connect to the LDAP server
Feb 15 10:39:21 sunidmtest02.qut.edu.au ldaplist[24684]: [ID 545954 user.error] libsldap: makeConnection: failed to open connection to ForestDnsZones.pgs.its.tils.qut.edu.au
—snip—I’m able to pull down the data using ldapsearch (and other tools from the SUNWlldap package) but these use different libraries. Anything that uses the libraris in the in the SUNWcsl package (/usr/lib/libldap.so and /usr/lib/liblsdap.so) appears to have the same problem.
The packet dump shows a successful bind, successful search query and then an unbind with AD. There doesn’t appear to be any failed LDAP bind or query anywhere. The LDAP libs don’t appear to be trying to use SSL/TLS or anything strange like that. So it seems to me that there’s an obscure configuration problem on the LDAP client side or the LDAP libs are not working correctly.
-
Finally figured this out. Once I set:
—snip—
ldapclient manual \
-a followReferrals=false
—snip—These both work:
getent passwd
ldaplist passwdIt seems the LDAP client libs tell you the bind failed if they can’t follow any of the referrals returned in the result set. So even though the right POSIX data was coming back from AD, the LDAP client was still saying the bind failed, which is not what was happening at all.
I believe this is because my ForestDnsZones OU was not configured correctly so referrals weren’t working. You don’t actually need this OU in AD for UNIX authentication to work so it seems safe to turn it off if you’re just testing. But in production with a properly configured DC you might want -a followReferrals=true.
So both getent and ldaplist (kind of … see below) now work against Windows AD 2008.
Something else I came across which might save others some time:
—snip—
ldaplist
ldaplist: Object not found (LDAP ERROR (12): Unavailable critical extension.)
—snip—I still get this error when running ldaplist without any argument/parameters or when running “ldaplist “. Ldaplist works if you point it at a specific database entry. E.g.
These fail:
ldaplist
ldaplist passwd
ldaplist groupThis succeeds:
ldaplist passwd posixuser1I believe it’s related to this issue:
The Solaris LDAP clients use 2 sort keys/attributes: “cn” and “uid” in the SSS control and AD 2008 has some extra constraints (as is often the case with MS products) that cause this to fail. It seems you can tweak this on your domain controllers but I haven’t drilled down on what effects this might have.
-
klist work fine
“Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host-280r@TCH.STI.COM.TWValid starting Expires Service principal
03/20/10 18:35:29 03/21/10 04:35:34 krbtgt/TCH.STI.COM.TW@TCH.STI.COM.TW
renew until 03/27/10 18:35:29″I have problem wiht ldap.
getent passwd dino
(return nothing)
Tell me, should “ldaplist” working ok ?
ldaplist
ldaplist passwd
return: Object not found (ldap error 12): Unavaible critical extensionMy ldapclient command is:
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=adjoin,cn=Users,dc=tch,dc=sti,dc=com,dc=tw \
-a proxyPassword=adjoin \
-a defaultSearchBase=dc=tch,dc=sti,dc=com,dc=tw \
-a domainName=tch.sti.com.tw \
-a defaultServerList=172.26.1.202 \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:gidnumber=gidNumber \
-a attributeMap=passwd:gecos=gecos \
-a attributeMap=passwd:gidnumber=gidNumber \
-a attributeMap=passwd:uidnumber=uidNumber \
-a attributeMap=passwd:homedirectory=unixHomeDirectory \
-a attributeMap=passwd:loginshell=loginShell \
-a attributeMap=shadow:shadowflag=shadowFlag \
-a attributeMap=shadow:userpassword=userPassword \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:dc=tch,dc=sti,dc=com,dc=tw?sub \
-a serviceSearchDescriptor=group:dc=tch,dc=sti,dc=com,dc=tw?sub \System:
Solaris 10 10/08, Window 2003R2 SP2How to resolve this problem?
-
Confirmed working in Solaris 11 Express! Thanks so much for the excellent write-up. Looking forward to more. =D
‹ Previous · 1 · 2 · 3
Site Sponsors
115 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2006/10/16/refined-solaris-10-ad-integration-instructions/trackback/