As with the procedure for authenticating Linux against Active Directory and providing Kerberos-based SSO with Apache, there are a few steps to be performed. Some of these steps are performed on the Active Directory side, some of them are performed on the Solaris 10 system.
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.
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 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 with Solaris.
- 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 my updated Linux-Windows Server 2003 R2 integration instructions, linked above.) 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. (Note that this is different than the instructions provided for integrating Linux. I have an article planned to discuss this in more detail, but for now just trust me.) 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 ready to move on to configuring the Solaris servers themselves.
Configuring Solaris (Each Server)
The following steps need to be performed on each Solaris server that will authenticate against Active Directory.
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
verify_ap_req_nofail = false
[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
}
Your particular information will need to be supplied here, of course, so you can’t simply copy and paste from here to the Solaris configuration file.
Of particular interest here is the “verify_ap_req_nofail = false†parameter. I’m still shaking out some TGT validation/verification errors, and this is currently the only way to make authentication work from Solaris. As soon as I get the validation/verification problems sorted out, I’ll post a new version of these instructions.
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.
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 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.
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.
How I Tested
I tested this configuration using Solaris 10 x86 6/06 (the June 2006 release) running as a VM under VMware ESX Server 3.0.0. Authentication was performed against a pair of virtual servers (one hosted on ESX 3.0.0, the other on ESX 2.5.3) running Windows Server 2003 R2, Standard Edition.
-
Does this apply to authenticating Solaris 9 with a 2003 R2 active directory?
-
I am not a Solaris expert. So, I can’t answer that authoritatively. It is my understanding that Solaris 9 did not include some of the same components as Solaris 10; however, it is also my understanding that you could install open source equivalents (i.e, MIT’s Kerberos, PADL’s nss_ldap, etc.) to get to the same end result. Of course, the configurations would be slightly different in those cases than what is described above.
-
Hey Scott,
Your Unix to AD instructions have been very helpful. I’ve been able to get them to work on RHEL 4, but I’m having some trouble with Solaris. It seems like the Kerberos side is working – I’m not using TGT validation and “kinit username” does not return anything when I put in the correct password. The troublesome part has been LDAP. I’ve configured my AD to accept anonymous browsing, and I adjusted my ldapclient command accordingly:
ldapclient manual \
-a credentialLevel=anonymous \
-a authenticationMethod=none \
-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?subHowever, “getent passwd” only returns local accounts, and ldapsearch returns: “Can’t connect to the LDAP server – Connection refused”. I know that the AD part is OK since RHEL 4 works correctly. Any thoughts?
Also, have you ever tried integrating HP-UX and AD?
Thanks,
Kevin -
Kevin,
Your LDAP configuration looks correct (I’m assuming that you substituted the correct values where applicable and that this isn’t an exact copy of your configuration). Is NSCD running? If so, have you tried restarting NSCD, or even disabling it? If I recall correctly, NSCD was disabled during my testing.
Also, be sure that your /etc/nsswitch.conf was updated properly.
I haven’t had the opportunity to integrate HP-UX and AD.
-
Kevin,
Did you get your Solaris integration working?
-
Hey Scott,
Sorry for the lack of replies – I’m still working on this. I actually decided to back up to Solaris 9, which of course has its own issues since it’s missing many of the features that come standard with Solaris 10. I’m also trying Linux (RHEL 4) but having some trouble there too. I gave up with anonymous browsing in favor of TGT validation. The one thing I don’t really like is having the bind user’s password in the ldap.conf file – it doesn’t matter if no one can really use that account – I know my security folks still won’t like it.
I spent a few days trying to implement the SSO solution using a Microsoft document:
http://www.microsoft.com/technet/itsolutions/cits/interopmigration/unix/usecdirw/08wsdsu.mspx
I liked this idea because it mentioned a tool called css_adkadmin (http://www.css-security.com/downloads.html), which you can use to create the key table file on the UNIX system and it will automatically create an account in Active Directory for you, and you can assign a random password as well. Seems like a great idea, but I’ve simply had a real tough time getting it to actually work! The tough part has actually been compiling some of the open source applications on Solaris 9 (even after following their instructions).
Enough of my rambling – do you have any ideas?
Thanks,
Kevin -
A number of people have asked about the Kerberos bind for the LDAP account, but I just haven’t had the time to test it yet. I hope to be able to test it next week when I am back in the office again.
I haven’t yet tried css_adkadmin, although I have heard about it; I just continue to use the manual method creating accounts (user accounts, not computer accounts) and using ktpass.exe to add the SPN and export the keytab.
As soon as I have the opportunity to test the Kerberos bind for LDAP, I’ll post more information here.
-
Thanks for this great post. I have now finally been able to set this up; using a combination of your site and the m$ documentation for their Directory Services For Unix. I have this running against W2K3r2 and am successfully using both kerberos and ldap.After setting it up I have 2 big questions.
Question 1: User Home Directories. Unfortunately I am in an environment where our info security will not let us use NFS. That means that the automounter and auto_home stuff will not work to have centralized directories for the user’s home. If I have to create a user home directory on each server (230 of them) that kinda scrubs one of the nice things about centralized user management. Is there a way that you know of to have the home directory created when a user first logs in, as well as if the user is deleted in AD removes the home directory from each server. Currently I am just creating group directories and having all users in a particular group home directory set to that directory. (These are all production servers and users shouldn’t be having personal files on them anyway)Question 2: Limiting Users to Certain Servers. Is there a way to do this since the servers are actually using a user account as opposed to a computer account to identify it to AD. The only way that I can think to get this to work is to have a seperate container for each group of servers. But if I do that how do I allow administrative users have access to all containers and be authenticated, authorized, etc.
Thanks for your excellent article!
-
Dale,
If you could find a Solaris port of pam_mkhomedir.so, that would work wonders for you. That’s a PAM module that can be used to automatically create a home directory if one does not already exist. I’ve used it extensively in the Linux world and it works well enough. Of course, it doesn’t delete home directories when accounts are removed from Active Directory, but at least it removes the administrative overhead of having to create the home directories on all the different servers.
With regards to host access, have a look at the article I wrote on using PAM and LDAP to limit access to servers based on group membership. That article’s written from a Linux perspective, but I would imagine that we could get it to work on Solaris as well if we tried hard enough.
-
Hi Scott,
I’m a litte bit confuse on -princ, -mapuser, -pass syntax. Mind to give me a hint?
ktpass -princ HOST/fqdn@REALM -mapuser DOMAIN\account
-crypto DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_PRINCIPAL
-out filenameThanks,
-Chris -
Chris,
HOST – This is just the word “HOST”. Although I specified uppercase in this article, I’d recommend lowercase instead. Refer to one of my follow up articles for more information.
fqdn – The fully qualified domain name of the server, i.e., solaris.example.net.
REALM – The Active Directory DNS domain name (i.e., example.net) in UPPERCASE. It must be in UPPERCASE.
DOMAIN – The NetBIOS name of the Active Directory domain.
account – The user account created for this server in Active Directory. Note that for a variety of reasons, this will probably be a user account and not a computer account.
filename – The name of the file in which to store the keytab that is being generated.
I hope this clears things up for you.
Scott
-
Hi Scott,
This seems to be a stupid question but I need to verify w/ you if it’s true or not. I got this response which was posted awhile back & here is the link:
What i’m trying to do is that I want all of my exiting AD users (which is in a few hundreds) to be able to log into my solaris machine using their existing login & passwd. Can I accomplish the task through your procedure or do I need to have a Sun Java System Identity Synchronization for Windows? Any helps/suggestions are greatly appreciated.
Thanks,
-Chris -
Chris,
See my response on the newer Solaris-AD integration article.
-
Hey Scott,
Thanks for this article, it really helped me along in getting kerb auth working against AD. I have not gone as far as using LDAP for authorization, but kerberos authentication is working great now.
I am having one problem with ssh shared keys, though. My basic method is to try kerberos and then unix via pam and comment users out of /etc/shadow to force them to go through AD. But when the user doesn’t exist in /etc/shadow, ssh shared keys stop working. If I put them back in shadow, it works fine until the local password expires and then nothing works.
Maybe I’m using the wrong method here. Butting them in shadow with NP and a 99999 expiration will work, but it feels insecure to me.
What do you do with the user’s /etc/shadow entry?
-
mm,
I haven’t tested SSH shared keys with Solaris after configuring it for Kerberos/LDAP, so I can’t really provide any advice on how I’ve been doing it. In my instances, I avoid a local /etc/passwd or /etc/shadow entry altogether, using Kerberos for authentication and LDAP for authorization and account information, so I imagine that SSH shared keys would continue to work as expected. I hope to have some time in the lab tomorrow afternoon, so I’ll give it whirl and see what happens.
-
mm,
I just tested authentication to Solaris 10 using SSH shared keys and didn’t run into any problems whatsoever. Of course, keep in mind that my installation of Solaris is configured for LDAP authorization and account information (/etc/nsswitch.conf references LDAP for passwd and group, and getent passwd or getent group retrieves information from Active Directory). It looks to me like the issue is simply one of not having account information available when the /etc/shadow entry is deleted and therefore logons can’t occur.
-
Hi
I am trying to configure ldap clint in sol 10 x86 not able to do so i am getting following errors in syslog
Nov 1 18:12:21 pamsol.pam.com ldap_cachemgr[5393]: [ID 178954 daemon.warning] l
ibc: bad lookup policy for hosts in /etc/nsswitch.conf, using defaults..and when i try ldaplist following error came
ldaplist: “Object not found (Session error no available conn.
) ” on console and in syslog it is( openConnection: simple bind failed – Invalid credentials)my nsswitch is as follow
#
# /etc/nsswitch.ldap:
#
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP in conjunction with files.
#
# “hosts:” and “services:” in this file are used only if the
# /etc/netconfig file has a “-” for nametoaddr_libs of “inet” transports.# LDAP service requires that svc:/network/ldap/client:default be enabled
# and online.# the following two lines obviate the “+” entry in /etc/passwd and /etc/group.
passwd: files ldap
group: files ldap# consult /etc “files” only if ldap is down.
hosts: ldap files pam.com
“/etc/nsswitch.conf” 50 lines, 1096 characters
—————————————————————————————————-
And my
bash-3.00# ldapclient manual /
-a credentialLevel=proxy /
-a authenticationMethod=simple /
-a proxyDN=cn=Administrator,dc=pam,dc=com -a proxyPassword=Track123! /
-a defaultSearchBase=dc=pam,dc=com /
-a domainName=pam.com /
-a defaultServerList=172.16.146.66 /
-a serviceSearchDescriptor=passwd:dc=pam,dc=com?sub /
-a serviceSearchDescriptor=group:dc=pam,dc=com?sub———————————————————————————————————-
but i am able to authenticate can u suggest what mistake i am making
Thanks in Advance for help -
Naveen,
It looks like the DN for your proxy account is incorrect–if your account is found in the default Users container you’ll need to use something like “cn=Administrator,cn=Users,dc=pam,dc=com”. Double-check the DN for your proxy account.
Scott
-
Give this a shot. It worked with Solaris 10 and W2K3 Server using SFU 3.5.
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=ldapsearch,ou=ldap,dc=test,dc=local \
-a proxyPassword=ldapsearch \
-a defaultSearchBase=dc=test,dc=local \
-a domainName=test.local \
-a “defaultServerList=192.168.20.100″ \
-a attributeMap=group:userpassword=msSFU30Password \
-a attributeMap=group:memberuid=msSFU30MemberUid \
-a attributeMap=group:gidnumber=msSFU30GidNumber \
-a attributeMap=passwd:gecos=msSFU30Gecos \
-a attributeMap=passwd:gidnumber=msSFU30GidNumber \
-a attributeMap=passwd:uidnumber=msSFU30UidNumber \
-a attributeMap=passwd:uid=sAMAccountName \
-a attributeMap=passwd:homedirectory=msSFU30HomeDirectory \
-a attributeMap=passwd:loginshell=msSFU30LoginShell \
-a attributeMap=shadow:shadowflag=msSFU30ShadowFlag \
-a attributeMap=shadow:userpassword=msSFU30Password \
-a attributeMap=shadow:uid=sAMAccountName \
-a objectClassMap=group:posixGroup=group \
-a objectClassMap=passwd:posixAccount=user \
-a objectClassMap=shadow:shadowAccount=user \
-a serviceSearchDescriptor=passwd:ou=users,ou=unix,dc=test,dc=local?sub \
-a serviceSearchDescriptor=group:ou=groups,ou=unix,dc=test,dc=local?sub -
Excellent! Thanks for sharing that LDAP configuration for SFU 3.5. That will come in handy for those not yet running Windows Server 2003 R2.
-
How did you get Solaris 10 LDAP and SSH shared keys to work? I can’t get it to work at all plus I just found this info on the Sun website. According to Sun LDAP and shared key logins will now work. Thanks in advance for your help.
-
Ed,
Keep in mind we’re only talking about the Solaris 10 LDAP client, not their Java System Directory Services (or whatever they’re calling it these days). The configuration was to use LDAP against Active Directory to retrieve account information (UID, home directory, etc.) and use Kerberos against Active Directory for authentication.
In this context, configuring SSH shared keys was strictly an SSH affair–I didn’t have to change anything outside the SSH configuration. It just worked.
By the way, it looks as if the link you posted in your comment refers to the Solaris 10 LDAP server, not the client.
Scott
-
Mr. Lowe,
Just found your blog — I think I’ve read some of the best blog entries EVER. I’ve set up AD / Kerberos / LDAP authentication with Solaris versions 2.6 – 9, and multiple variants of Linux (Slackware, Redhat, Fredora). All of this is good stuff.
As for ssh shared keys, I believe (unless I have it misconfigured) that ssh shared keys defeat the purpose of pam_krb5.so. That is, if you’re authenticating a user with an ssh shared key, and the user types “klist,” then there wil be no Kerberos TGT.
Further, as for mm’s post, I’d bet that ssh is referencing PAM, even though you’re using an SSH shared key, and your PAM.conf options are either wrong (sufficiant vs. required), or in the wrong order. As far as I know, you only need LDAP to *identify the user*, and Kerberos / SSH shared keys will take care of the actual authentication piece.
I’ll also be looking at that adkadmin utility also, just for the easiness of it. I’m about to go into round 2 of our Active Directory deployment, moving from AD 2000 to AD 2003 R2, so it’ll be pretty fun!
-
Greg,
Thanks for the feedback! I’m glad to hear that others are finding this stuff as interesting as I do.
With regards to SSH shared keys and Kerberos, I believe you’re right. You would lose your TGT. If what the user is truly seeking is passwordless login, that can be accomplished by allowing GSSAPI authentication.
I would imagine that you’re also right on track with regards to mm’s problem with user accounts.
Good luck with your 2000-to-2003 R2 upgrade. Let me know if I can be of any help!
Scott
-
Heya,
I ran into snags (as anyone almost certainly will). Specifically, your solution left LDAP over SSL out — I used this document as my guide to getting LDAP over TLS working:
(Actually, Kevin linked to this document above, I just wanted to recount its usefulness.) The other thing you MUST do is use a LOCAL copy of Mozilla (on the Solaris server!) to download the cert8.db, key3.db and secmod.db files. I used the copy of Mozilla on my macbook and copied those files to /var/ldap, but ldaplist wouldn’t work. Running truss, I found my system tryng to locate Mac libraries.
Finally, your ldapclient script sets this up:
-a serviceSearchDescriptor=passwd:dc=example,dc=com?sub \
-a serviceSearchDescriptor=group:dc=example,dc=com?subBut I found that running id took FOREVER to return, so I changed it:
-a serviceSearchDescriptor=passwd:cn=Users,dc=adtest,dc=org?sub \
-a serviceSearchDescriptor=group:cn=Users,dc=adtest,dc=org?subThen my search results became much faster. I suspect there’s an indexing issue going on somehow.
-
Greg,
I specifically did not tackle LDAP over TLS/SSL because of some of the complexities involved; I do plan to address that here soon. Thanks for the additional referral back to Microsoft’s documentation; I’ll be sure to review that when I get ready to work on the LDAP over TLS/SSL issue.
With regards to the serviceSearchDescriptor, you’re absolutely right in two different areas:
- First, users should ABSOLUTELY narrow the search down, if that can be done. I typically recommend to customers to leave the built-in Users container alone (leave it for system-created accounts) and create a single organizational unit in which to store all their user, group, and computer objects (subdivided/organized however the customer desires). If, however, the customer sprinkles the OUs around the top level of the domain, then the serviceSearchDescriptor can’t be narrowed down.
- Second, there is DEFINITELY an indexing problem. By default, the uid attribute (which is what the Solaris boxes are searching on) is not indexed in Active Directory. I alluded to this problem in this post:
http://blog.scottlowe.org/2006/08/21/more-on-kerberos-authentication-against-active-directory/
I have also recommended that uid be indexed in these instructions; see step 2 under “Preparing Active Directory (One-Time)”, above). Indexing this attribute has, in my experience, made a world of difference in performance.
Thanks,
Scott -
Hi Scott,
I just want to say your document helped me setup Solaris 10 and AD very easily. I also wanted to point out that I don’t know if you found out, but you can add other OU’s to a ServiceSearchDescriptor. The syntax would be something like this:
-a serviceSearchDescriptor=passwd:ou=Unix Admins,;ou=Unix Users,;dc=example,dc=com?sub
We currently are using Vintela for our integration. I just used the pre-existing entries that Vintela used to update our schema with. I also was able to add all of my NIS Maps to AD without using Vintela or NFS Server for Unix. I added the automount attributes and classes by hand. I then created a separate OU and added all my maps using ADSIedit. I made a container with each map name and those containers contained the map data.
-
SteveC,
Thanks for the tip! I was not aware of that syntax. That will be very helpful in situations where AD architects have not consolidated all the users into a single tree (I see it all too often). Do you have a URL where that syntax is described?
If you have the time, I’d love to see more information on your NIS integration with AD. Perhaps you can send me some of that information via e-mail? My address is scott dot lowe at scottlowe dot org.
Thanks!
-
Good directions for a single AD domain, thanks. Do you have any ideas on the configuration for multiple domains, or multiple child domains that we would want to authenticate to?
-
Christian,
Redirecting the LDAP queries to the Global Catalog port (TCP 3268) instead of standard LDAP (TCP 389) should take care of the name services. As far as Kerberos goes, if DNS lookup for KDCs is enabled, then it should be able to locate a KDC for each domain via DNS. If not, then you’ll need to specify the realms (i.e., AD domains) in the /etc/krb5/krb5.conf file.
Let me know how it goes!
-
Good day.
I’m new to solaris OS and I only have Solaris 10 1/6 version. Therefore, did follow your instructions, but unfortunately I cannot proceed it because i got no return after ran “getend passwd . kindly guide me.May I know what is user account should be used during the “ldapclient” configuration? AD’s “Administrator” account? and, what user account should be used as running “kinit ”
Do I need to run any command on the generated solarissvr.keytab file, in my solaris computer?
Please guide me.
many thanks,
-
Good day.
I followed your instructions, but could not get any return as ran “getent passwd . kindly guide. -
Scott,
Thanks a million for this write-up! It is such a huge administrative load lifted, now that I can authenticate my Solaris users to AD. It is also helping tremendously with PCI compliance.
SteveC,
Thanks to you, for providing the syntax for adding another search descriptor. I have been searching for this for weeks, and got no responses on BigAdmin. We have separate user OUs for each of our geographical locations, and it was absolutely maddening having to ditch that methodology and put all the Unix users into one special OU.
-
Slowe,
first of all thanks for your great work on interoperability.
I got it to work but I don’t manage to allow my users to change there password from the Solaris prompt.
I believe my pam.conf allows that, but this is not behaving as expected :
other password required pam_dhkeys.so.1
other password requisite pam_authtok_get.so.1
other password requisite pam_authtok_check.so.1
other password sufficient pam_krb5.so.1 use_first_pass
other password required pam_authtok_store.so.1the result of a passwd request is as follow :
dany@solaris8 # passwd
passwd: Changing password for dany
Enter existing login password:
New Password:
Re-enter new Password:
New Kerberos password:
Re-enter new Kerberos password:
Kerberos password not changed:
Password change rejectedPermission denied
dany@solaris8 #So my questions are :
Why is that rejected ?
Why is the first password change request local ?Checks :
-No logs of any reject are visible in the security audit.
-The password is respecting complexity.
-The user is authorized to change his password -
Dany,
All of my integration solutions currently do not provide for changing the password from the UNIX side of the house. That’s something that I’ve had on my list of “things to do” but have yet to actually find time to get it done.
-
I followed the setup but when my Solaris box queries AD I get an error:
resultCode: unavailableCriticalExtension (12)
I think it is related to VLV support, but I don’t know how get around this. I am using w2k3 R2.
Item sortKeyList
Item LDAP_CONTROL_VLVREQUEST VLVMarkus
-
I found that I can disable VLVs with ntdsutil.exe
by selecting configuration settings and the setting disable VLV to 1.Did anybody else need to do that ?
Markus
-
Hi Scott,
Your guide has been very helpful. I’ve been able to get it working on Solaris 10. I have one question regarding keytab file.
I could make authentication to AD working without creating a keytab. I just created an empty keytab on the Solaris machine and it works.
Is there any harm for doing this?Thank you for your time,
Mohammed -
Hi Mohammed, from what I understand, if you have verify_ap_req_nofail set to false in krb5.conf, that is what you will see. If you have it set to true, I am pretty sure that the keytab file verified. I believe that it is desired to have this set to true, for better security.
-
Forgot to mention that if you follow the ktpass example exactly as it is here, you will not be able to get this to work if you switch verify_ap_req_nofail to true. The ktpass example here, uses HOST/fqdn@REALM. When I switched the HOST portion to lowercase, I was able to set “verify_ap_req_nofail = true”, and successfully logon. If you do not remember if you used upper or lower case, you can look in AD at the account you created, and go to the account tab. In that tab, have a look at the “User logon name”, as it will report what you specified with ktpass. If this has host in lowercase and there are no other issues with your keytab file, then this should work when you set it to “true”
-
I have multiple unix users but they are required to log on to the linux servers with the same home directory. Any ideas on what need to be done to enable this? Once i try to log on as the second user on this list of users, it comes up with user does not exist.
-
Folu,
I’m not sure about the “user does not exist” error, but in order to have multiple users utilize the same home directory you’ll need to adjust the UNIX file system permissions on that home directory. There are numerous resources elsewhere that can describe that process for you in great detail, so I won’t go into that here.
-
Hi,
Great article. I was mainly interested in the host kerberos authenication to AD. I assumed this wouldn’t need the NIS component in AD but I continually get
kinit(v5): Key table entry not found while getting initial credentials
config is exactly as you’ve documented on Sol10.
Any ideas?
Gary
-
When I use multiple domain (Using 3268) ldaplist passwd works but get passwd not working, so authentication is not happening.
Somebody help me if you have any experience on it.
-
Hi,
I am trying to use NISnetgroup created in ADS through my solaris 10 ldapclient.
Basically I am trying to setup Solaris authentication using ldap client and windows ADS. (as replacement of NIS).
Please suggest good client configuration and configuration changes on ADS if any.
Without netgroups, I am able to authenticate users of ADS.
Any help will be a great help to me.
-
Hi i am looking for a process document or user guide how can integrate solares, 7, 8,9,10 to actie directory , In order to migrate all users to active directory
tx -
Dears,
I am a little bit confused, when to use the authentication bind account we created and when to use the user account (created for each host) in below command:
ldapclient manual \
-a credentialLevel=anonymous \
-a authenticationMethod=none \
-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?subplease help
-
Excellent post, very helpful!
One thing I noticed on my clients running Solaris 10 10/09 is that getent cannot enumerate the users or groups and also finger username fails when I use the objectClassMap provided in your examples.
What works are logins with domainaccounts and also getent username finds the user. Does that work on your setup as expected?
If i leave out the objectclassmap and instead give the user the additional objectclass posixaccount everything works including finger and getting the user/group list with getent. -
Thank you so much for this detailed post. It’s quite useful and it clears me a lot of things about AD integration with Solaris 10.
In the end, I’ve done the level of integration that I need using a third-party free product (LikeWise Open http://www.likewiseopen.org/ ). I’m an IBM Rational ClearCase Administrator and using this product my users can view the network drives that the application use regardless which OS they’re using and sharing a synchronized login. SSO it’s the next step for us, but before to find an get LikeWise up and running this document was really useful for me and my team.
Cheers and keep the good work.Juan Pablo Soto
IBM Rational Consultant -
Hi Scott
Thanks for a great blog it’s helped clarify things a lot for me.
Is there any way you know to integrate the solaris /etc/user_attr file into Windows 2008 AD ?
Site Sponsors
56 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2006/08/15/solaris-10-and-active-directory-integration/trackback/