Solaris 10-AD Integration, Version 3

Wednesday, April 25, 2007 in Interoperability, Microsoft, UNIX by slowe | 156 comments

Thanks to some very helpful individuals in the #solaris channel on irc.freenode.net, I’ve been able to get ADS support working in Samba on Solaris 10, and thus have been able to incorporate the use of Samba in the Solaris 10-AD integration instructions.

To refer to earlier versions of the Solaris 10-AD integration instructions, see this article or this article. I would expect that you won’t need to refer to those posts, though, and will be able to get most of what you need directly from this post.

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. (I only have a single article written that includes pre-R2 attribute mapping, and that’s this Linux-AD article. The schema mapping should be very, very similar between that article and Solaris 10.)

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. The only workarounds I’ve found to address these issues is the clever use of symlinks and the use of NFS automounts for home directories.

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.

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, and ensure that both forward and reverse lookups work from each of the Solaris server(s).

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).

Installing Blastwave Packages

This is the key to getting ADS support into Samba on Solaris 10. I won’t go into excruciating detail on this since this process is amply covered elsewhere, but here’s the basic idea of the process:

Use the standard wget (found in /usr/sfw/bin) to download the pkg-get file used by Blastwave.
Use pkgadd to install pkg-get.
Configure pkg-get to use the unstable packages (makes sure you get the latest builds).
Use pkg-get to install the CSWsamba package and all requisite packages (there were quite a few dependency packages during my testing).

Once the CSWsamba package and related packages are installed, we’ll need to configure Samba by creating /opt/csw/etc/samba/smb.conf with the following contents:

workgroup = <NetBIOS name of AD domain> security = ads realm = <DNS name of AD domain in UPPERCASE> use kerberos keytab = true password server = <Space-delimited list of AD DCs>

At this point, we are ready to configure Kerberos and then proceed with testing the configuration and join the Active Directory domain.

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 }

There will also be a file named cswkrb5.conf in the /etc directory; you can configure this file with the contents of the [libdefaults], [reamls], and [domain_realms] sections as listed above. You don’t need to include the [logging] or [appdefaults] sections in this file.

Note that you can’t simply copy and paste from here to the Solaris configuration files, as you’ll need to customize your version for your particular network, hostnames, domain names, etc. If you must copy and paste from here, put it into a text editor first to customize it for your implementation.

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 the “nslookup” command. As mentioned previously, be sure to test both forward and reverse lookups.

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 join the Solaris server to Active Directory using Samba.

Joining the Solaris Server to Active Directory

This is the final step. Don’t try this step until you’ve successfully tested the configuration. After this step is completed, you are finished and AD users will be able to login to the Solaris server (assuming the AD users have been properly configured).

To join the Solaris server to Active Directory, follow these steps:

Verify the Samba configuration as outlined earlier. Key to the configuration are the “security = ads” and “use kerberos keytab = true” directives.
Use “kdestroy” to destroy any existing Kerberos credentials you may have; then run “kinit <Domain administrative account>@AD.DOMAIN.NAME” to get a Kerberos ticket for an account that is a domain administrator account.
Run “net ads join” to join the Solaris server to Active Directory. This command will automatically create a computer object in Active Directory and add the appropriate SPNs (service principal names) to the computer object. In addition, it will populate the local Kerberos key table (/etc/krb5.keytab, by default) with the correct entries for authentication against Active Directory. You may see an error about a missing userPrincipalName, but this does not appear to affect any functionality.

At this point, all properly configured AD users (those users who have UNIX attributes) should be able to login to the Solaris server using their Active Directory username and password. Of course, this assumes that you’ve already dealt with home directories (or are automounting home directories).

As with previous instructions, these instructions don’t address password management (the ability to change an AD password from Solaris) and don’t address how to handle home directories. Hey, I’ve got to leave a few challenges for others to tackle, right?

How I Tested

This testing was done using Solaris 10 11/06 (Update 3) running on VMware ESX Server 3.0.1. Active Directory was running on a pair of servers with Windows Server 2003 R2, also virtual machines on ESX Server. Authentication testing was performed using SSH from a client system running Mac OS X.

Tags: ActiveDirectory, Interoperability, Kerberos, LDAP, Microsoft, Solaris, SSH, UNIX

156 comments

Comments feed for this article

Trackback link: http://blog.scottlowe.org/2007/04/25/solaris-10-ad-integration-version-3/trackback/

Tim on Friday, September 21, 2007 at 5:23 pm

Christian,

Our problem is that AD stores each group member as a full DN. The only solution I’ve found so far is the suggestion to create a new attribute for groups in the schema, and populate each member (more than likely this will be for the third time) as a single CN.

This is obviously a ludicrous proposition, because it’s highly inefficient and would be atrocious to maintain. We’d end up with groups which have each person listed as a “member:” attribute (for Windows), and a “msfu30posixmember:” attribute (for AD’s SFU), and then as whatever this new one is.

From what I can gather, if we’re to get secondary groups to work, Solaris would somehow have to map each member’s DN back to a CN.
(groupOfUniqueNames, or groupOfNames?) getent, by itself, shows us what objectclass Solaris is expecting to find each member within a group.

If anybody knows how to do this, or if indeed it’s even possible… please let me know. It’s killing me!
slowe on Friday, September 21, 2007 at 8:23 pm

Balaji,

I wish I could help, but I really don’t know. Sorry!
Balaji mariyappan on Tuesday, October 2, 2007 at 2:14 pm

Slowe,

Do you have any idea how a condition can be applied in servicesearchdescriptor.

thanks in adv
Balaji
slowe on Tuesday, October 2, 2007 at 4:53 pm

Balaji,

I’m sorry, I don’t. I’m trying to learn more about Solaris, but it’s slow going. I wish I could be more helpful.
Rudolph on Saturday, October 6, 2007 at 12:30 pm

Thanks for excellent information. I’m trying to replace our Sun Directory server with Active Directory. Unfortunately, we have a lot of solaris server profiles stored in the directory. Consequently my requirement is to run ldapclient against Active Directory to pull down a profile. I’ve extended AD to include the Solaris profile related classes and attributes-
(Classes called “nisdomainobject” and “DUAConfigprofile” and attribute “nisdomain” and others).

When I run ldaplclient I get the following:

# /usr/sbin/ldapclient -v init -a proxyDN=CN=apcproxy,OU=unixProfiles,DC=apc,DC=unix -a proxyPassword=password -a domainName=apc.unix -a profileName=CN=soltest1,CN=apc,OU=unixProfiles,DC=apc,DC=unix labtst1
Parsing proxyDN=CN=apcproxy,OU=unixProfiles,DC=apc,DC=unix
Parsing proxyPassword=password
Parsing domainName=apc.unix
Parsing profileName=CN=soltest1,CN=apc,OU=unixProfiles,DC=apc,DC=unix
Arguments parsed:
domainName: apc.unix
proxyDN: CN=apcproxy,OU=unixProfiles,DC=apc,DC=unix
profileName: CN=soltest1,CN=apc,OU=unixProfiles,DC=apc,DC=unix
proxyPassword: password
defaultServerList: labtst1
Handling init option
About to configure machine by downloading a profile
findBaseDN: begins
findBaseDN: ldap not running
findBaseDN: calling __ns_ldap_default_config()
found 5 namingcontexts
findBaseDN: __ns_ldap_list(NULL, “(&(objectclass=nisDomainObject)(nisdomain=apc.unix))”
rootDN[0] DC=apc,DC=unix
NOTFOUND:Could not find the nisDomainObject for DN DC=apc,DC=unix
found_cxt = -1
findBaseDN: Err exit
Failed to find defaultSearchBase for domain apc.unix

I’ve confirmed via a network trace that AD returns the DN of the organizational unit holding my solaris profiles.

Any advice would be appreciated. Thanks.
Bras on Sunday, October 14, 2007 at 10:53 am

Hello Slowe, Hello all,

I’m trying to use your method to integrate a Samba server (Solaris 10 11/06 Sparc) to Windows 2003 AD server.
But when I add this line :
“other account required pam_ldap.so.1″, then root cannot connected to the Samba server! What is wrong? Is the root account must be also created on the AD server ? I dont undertand well who LDAP must manage the accounts : AD LDAP or Samba LDAP ?

Thanks
Christian on Wednesday, October 17, 2007 at 2:12 pm

As far as the full dn for group info goes, in looking at my active directory setup, it looks like I don’t have a memberuid attribute. The best I have is the member attribute which is a users full dn.

This means group info still does not work, but since I’m seeing reference to this memberuid attribute is there something wrong with my active directory setup?

If I change the ldapclient command to point
attributeMap=group:memberuid=member

I can get output from getent group like:
cens_test2::1201:CN=mcm75,CN=Users,DC=nau,DC=froot,DC=nau,DC=edu

Any ideas? Is my ad schema wrong since I don’t have a memberuid attribute?

Thanks
Daniel Luneau on Monday, October 29, 2007 at 11:11 am

Hi Scott,

we successfully setup the integration of our Solaris 10 servers and zones to our Windows 2003 R2 AD. Now that we have more users using our servers, we run into a strange problem. The name-service-cache daemon (NSCD) is opening many (too many, about 1000 in 2 hours) connections to the AD and leaves it open. After a while, the NSCD process reach is file descriptor limits and the integration stop working. Any ideas why nscd open so many connections?
slowe on Monday, October 29, 2007 at 12:21 pm

Daniel,

I have a vague recollection of another reader who was having the same problem. Let me look back through some of my notes and see if I can find a possible resolution.
John G on Thursday, November 1, 2007 at 8:24 pm

Hi Scott and others,

I was reading with interest the posts about secondary groups, hoping that someone had got this working, then it occurred to me that this could possibly be a reporting issue with the ‘groups’ command rather than a functional issue.

I made a user a member of multiple unix groups in AD. “groups” for that user reported only a single group (not even the primary), however “getent group” reported the group members correctly.

When I created directories with various group permissions, my access to those directories was restricted correctly for the multiple groups. So, at a pure Unix level, it appears that secondary groups do ‘function’ correctly.

So it would seem that that the OS can find out “which users are members of a group” correctly, and only has an issue reporting “which groups a user is a member of.” Based on the discussions I have seen around LDAP/AD , this makes logical sense.

I will do more testing myself, but for any of those users who need secondary group functionality, I would be interested in your feedback – you may already have it – or may be able to modify your environment to work.

Hope this helps someone.

Cheers
John
slowe on Thursday, November 1, 2007 at 8:30 pm

John,

Excellent work–thanks for sharing that information with us! Please keep us posted on any further developments or information you gather.
John G on Thursday, November 1, 2007 at 11:36 pm

OK, now I have what may seem like a dumb question. I’ve setup a fresh Solaris 10 box and followed all the instructions except for installing Blastwave Samba and joining the domain. Everything seems to be working and users can login using their AD credentials. There is no krb5.keytab file in existence on the system.

So is my understanding correct that the Samba steps are unnecessary if all you want is login authentication to the box ? Or am I going to come across some sort of problem later on ?

Cheers
J
shawn on Friday, November 2, 2007 at 1:57 am

Scott,

First, thank you for taking the time to put this all together and also for helping troubleshoot everyones issues.

I’ve been through all the posts here, and all over google as well, trying everything that everyone else has done to get Solaris 10 to authenticate with Active Directory. I think I am pretty close, just not quite there yet, and I believe my issue has to be with my ldap config. I can to an ldapsearch and get information back, but if I do any sort of ldaplist, I get the following error:

ldaplist: Object not found (Session error no available conn.)

kinit seems to work fine, as does klist, but when I run any getent commands, the only data returned, is what is found in the Solaris servers local files. Any advice is greatly appreciated.
slowe on Friday, November 2, 2007 at 6:53 am

John G,

The keytab is necessary if you want to enforce TGT validation (i.e., to have the Solaris server validate the identity of the KDC that is issuing the TGT). If you don’t care about TGT validation, then the keytab isn’t necessary for authentication.

We use the Samba parts as a means to generate the keytab and the associated Service Principal Names (SPNs) in Active Directory. If you don’t need the keytab, then you don’t need SPNs in AD, and therefore don’t need Samba.

Shawn,

Make sure you’ve edited the /etc/nsswitch.conf and that you’ve run ldapclient to configure the LDAP client on Solaris. You may also find it necessary to restart the name service caching daemon.
shawn on Friday, November 2, 2007 at 11:52 am

Thanks Scott, I have updated nsswitch.conf and restarted nscd. I actually rebooted the server as well. I ran ldapclient, and made sure I had the correct proxyDN, by running a dsquery on the domain controller. I just can’t seem to figure out why the ldapsearch is working, but the ldaplist fails and getent only returns local data. I’m still plugging away at this, trying small changes here and there, but if you have any other things to check, that I may have over looked, any advice is much appreciated.

Shawn
shawn on Friday, November 2, 2007 at 1:05 pm

ok, so I think I have been ignoring the information all along. For some reason, I thought I read that if using SFU3.5, I am supposed to use the same ldapclient settings as the 2003R2 settings. I’ve finally realized that you have been saying these settings assume 2003R2 all along, and that SFU3.0 and 3.5 should use the following settings for ldapclient

-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 \

Can you please confirm this for me, one last time. Should these attribute maps be used for SFU3.0 and SFU3.5? Also, where should I be able to look at this and verify, on the domain controller?

Thanks again for your help…
shawn on Friday, November 2, 2007 at 1:49 pm

OK, sorry for all the posts, just want to up date my progress, so no one wastes their time replying to my other posts. After finally listening to what you’ve been saying all along, I am using the attributeMap entries for SFU3.5, which if anyone was making the same mistake, all need the msSFU30 prefix. I can now successfully run the ldaplist commands and can “su” to an account on my solaris server. My only issue now, is that I can not ssh in, I receive the following error:

Nov 2 11:39:03 wwwddcissuppi01 sshd[800]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found

I assume this is probably due to an error in pam.conf, but it looks like I have it correct. If you already have a good idea of where my problem is, based on the symptoms, please let me know.

Thanks
shawn on Friday, November 2, 2007 at 3:17 pm

Thought I found my issue, because someone else has the same symptoms that I did, able to run ldaplist , ldapsearch, klist, kinit, and able to su to the user, but not able to telnet /ssh in. I tried re-generating my keytab files, and noticed that the account name was too long and being chopped off. I re-created the accounts with shorter names, created new keytab files, and transfered them over to the solaris servers. I was feeling confident, but still unable to ssh to the server, and receiving the same error.

Hoping someone can suggest anything, as I have got to be very close to getting this working.

Thanks..
shawn on Friday, November 2, 2007 at 7:48 pm

Still no luck for me, but I am starting to lean towards the fact that my issue is probably an encryption issue. Can anyone that has this working between Solaris 10 and 2003 Server with SFU3.5 please confirm what encryption method is being used. While generating the keytab file with ktpass, I have tried specifying “-crypto DES-CBC-MD5″, “-crypto DES-CBC-MD5 +DesOnly”, and without the -crypto option altogether. None of these seem to work, unless I need to change things else where as well.

Also, on the domain controllers, if I open “services for unix administration”, there is an option in there to use MD5 or crypto. I’ve tried both, but do I need to regenerate the my keytab file if I make the change?

I seem to be monopolizing this blog today, but again, if anyone has any ideas for me to try, please let me know. I really need to get this working (as many others before me have already said).
slowe on Saturday, November 3, 2007 at 9:53 am

Shawn,

What kind of error messages are being logged on the Solaris server(s)? You may want to turn up the logging level on the sshd daemon so that we get more information to help us isolate the problem.
shawn on Saturday, November 3, 2007 at 3:37 pm

The only error message I receive, is the following:

sshd[1433]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Key table entry not found

I have tried adding a debug entry to pam.conf, for “other auth sufficient pam_krb5.so.1″, but when I do this and attempt a new ssh connection to the server, the attempt just fails and nothing is logged. On the server I try to ssh from, I just receive “connection closed by $SERVER_IP”. I tried to increase sshd logging to debug as well, and again the same occurs.

I am trying to get a second server to test with, so I can rule out the server itself, but not having much luck from the powers above. In the mean time, I have to keep plugging away with this server. I have spent a few late nights on this so far, and it’s driving me crazy. Is it possible that the encryption method I am using to generate the keytab, isn’t supported by the solaris server? Also, in an attempt to try and speed up my troubleshooting, I have generated 3 keytab files, one with des-cbc-md5, one with des-cbc-md5 +DesOnly, and one without specifying the -crypto flag at all. My plan was to just copy each one over to kerb5.keytab, anytime I made a chnage to things. Is this a waste of time? I ask because I read somewhere that the KVNO number in the keytab gets incremented each time you run ktpass, which I can see when I run a klist against the keytab files. So, are any keytab files generated previously, just a waste of time, will only the most recent one work? Sorry for all of the questions, but again, thanks for any assistance.

If it helps, I have Solaris 10 and SFU3.5 on Windows 2003 (not R2).

HERE IS MY KRB5.CONF

[libdefaults]
default_realm = NACHO.MAMA.COM
dns_lookup_kdc = true
default_checksum = rsa-md5
default_tkt_enctypes = des-cbc-md5 ; or des-cbc-crc
default_tgs_enctypes = des-cbc-md5 ; or des-cbc-crc
default_keytab_name = /etc/krb5/krb5.keytab

[realms]
NACHO.MAMA.COM = {
kdc = wwwddciwdconi01.nacho.mama.com
# kdc = wwwddciwdconi02.nacho.mama..com
admin_server = wwwddciwdconi01.nacho.mama.com
}

[domain_realm]
.nacho.mama.com = NACHO.MAMA.COM
.subdomain.nacho.mama.com = NACHO.MAMA.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
}
pam = {
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}

HERE ARE MY LDAP CLIENT SETTINGS

NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= CN=solarisldap,OU=Users,OU=Associates,dc=nacho,dc=mama,dc=com
NS_LDAP_BINDPASSWD= {XXX}XXXXXXXXXXXX
NS_LDAP_SERVERS= 10.25.240.21
NS_LDAP_SEARCH_BASEDN= dc=nacho,dc=mama,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:dc=nacho,dc=mama,dc=com?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:dc=nacho,dc=mama,dc=com?sub
NS_LDAP_ATTRIBUTEMAP= group:userpassword=msSFU30Password
NS_LDAP_ATTRIBUTEMAP= group:memberuid=msSFU30MemberUid
NS_LDAP_ATTRIBUTEMAP= group:gidnumber=msSFU30GidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:gecos=msSFU30Gecos
NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=msSFU30GidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=msSFU30UidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:uid=sAMAccountName
NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=msSFU30HomeDirectory
NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=msSFU30LoginShell
NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=msSFU30ShadowFlag
NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=msSFU30Password
NS_LDAP_ATTRIBUTEMAP= shadow:uid=sAMAAccountName
NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group
NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user
NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user

HERE IS MY PAM.CONF (other settings)

root@wwwddcissuppi01$cat /etc/pam.conf | grep other
# defined in the “other” section.
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
other account requisite pam_roles.so.1
other account sufficient pam_unix_account.so.1
other account required pam_ldap.so.1
other session required pam_unix_session.so.1
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 required pam_authtok_store.so.1

With these settings, I can do pretty much anything I need, accept the most important part, authenticate AD users. Sorry for the long post, appreciate any help, and I’ll update with any progress.

Shawn
shawn on Sunday, November 4, 2007 at 5:56 pm

Finally got things working last night, to be honest I’m not really sure what the final fix was. I think it’s safe to say that along the way I made every possible mistake in the process. So, thanks to every one that has posted info here, mainly your mistakes/issues have gotten me to a working point. Scott, thank you so much for putting all of this together. For the most part, if I had slowed down and carefully read your caveats, I would have finished a lot sooner.

Now that I’ve said my thank yous, I have to ask one more question, and see if anyone has fixed this. If I authenticate as an AD user, and then sudo to root, the KRB5CCNAME file, which stores in /tmp in my env., gets updated with root ownership. This doesn’t prevent me from logging in, but until I correct the ownership or remove the file, it generates a couple unwanted messages. This isn’t a big deal now, but if there are hundreds of people logging and doing some form or sudo, it could end up polluting the system log quite a bit. if anyone has any info on this, please do tell. Here are the log entries I receive:

Nov 4 14:22:52 wwwddcissuppi01 sshd[1308]: [ID 375328 auth.error] PAM-KRB5 (setcred): Cannot find creds for smithjo@NACHO.MAMA.COM (Credentials cache file permissions incorrect)
Nov 4 14:22:52 wwwddcissuppi01 sshd[1308]: [ID 720393 auth.error] PAM-KRB5 (setcred): pam_setcred failed for smithjo (Failure setting user credentials).

Thanks again, I’m now off to think about what to do about home directories, so I don’t have to manually create them.
shawn on Monday, November 5, 2007 at 4:09 pm

As several have already said here, pam_mkhomedir.so works great for me, to create user home directories. I followed the steps at http://www.webservertalk.com/message1674632.html and it works like a champ. Reading the posts here, I wasn’t too confident that it would be as easy as it was. If anyone else is looking to add creating home directories when a new user logs on, definitely take a look.

So, functionally I am all set now. If anyone happens to know anything about the issue with changing the permissions of the KRB5CCNAME file when doing a sudo, please let me know.
Nick on Tuesday, November 6, 2007 at 5:32 am

John, you say you got getent group to show the correct list of groups, is that as just a list of group names (as we want) or as a list of distinguished names? If the former then please post your ldap client config!
John G on Wednesday, November 7, 2007 at 12:41 am

Hi Nick,

My ldapclient file is as per the instructions here.

I might not have explained that clearly, “getent group groupname” will show all the *members* of a group correctly, as userids. I’ve also found some other interesting anomalies in more testing just now. I’ll try to summarise what I am seeing:

I am logged in via SSH as jgeorges@host. Primary group is set to aaa. In AD, my userid is a member of aaa, bbb and ccc

$ groups
bbb
– Incorrect response
– this is not even the primary group

$ groups jgeorges
aaa bbb ccc
– Correct response!
– using ‘groups $LOGNAME’ would be a generic alternative

$ getent group aaa
aaa::101:rjo,jgeorges,dsimonet
– Correct response!

So it is looking more like just “groups” on its own fails.

To overcome this, you could setup a systemwide command alias:

alias groups=”groups $LOGNAME”

If you put this in /etc/profile, any user who ran “groups” will start getting the correct responses back from the system.

Hope this clarifies, and helps.

John
Daniel Luneau on Wednesday, November 14, 2007 at 8:51 am

Hi Scott, did you had the time to check your note for nscd daemon that doesn’t close its connection to the Active Directory and eventually reach it’s file descriptor limit?

Thanks again

Daniel
slowe on Wednesday, November 14, 2007 at 9:48 am

Daniel,

My memory must be faulty, as I couldn’t find any discussions I’d had about NSCD. I thought that another reader had run into the same problem, but I must have been mistaken. Sorry! As I have some spare time over the next few days, I’ll see if anything turns up and let you know here in the comments if I find anything.
shawn on Thursday, November 15, 2007 at 12:33 pm

Scott, can I setup my pam.conf up, so that it prompts for the AD password first, and then asks for the local account password if the AD password is not found? Here is a snip from my pam.conf, which I configured to check for AD first.

# Default definitions for Authentication management
# Used when service name is not explicitly mentioned for authentication
#
other auth sufficient pam_krb5.so.1
other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1
slowe on Friday, November 16, 2007 at 11:49 am

Shawn,

In the Linux world–which is a very different world, yes–that is the default behavior unless you use the “use_first_pass” or “try_first_pass” parameters. On Solaris, I’m just not sure. I would guess that the configuration as it stands right now does not produce the desired result?
Johan Fredriksson on Monday, November 26, 2007 at 4:17 am

I’ve spent three weeks trying to get this to work, blaming/bashing solaris 10 and cursing. Keytable entry not found and core dumps… truss didn’t reveal much (although I must admit I’m a Windows-guy and my knowledge of Solaris is somewhat limited).

However, I found a solution to my problem and I hope this post will help others that are stuck with the same problem and symptoms. My mistake was using Windows Support Tools Service Pack 1 (and 2). This did not work at all for me, but regressing to ktpass.exe from Windows 2003 WITHOUT servicepacks whatsoever solved everything.

I assume if you’re using the Blastwave approach this will not be a problem for you… But if you’re determined that you don’t need cifs/samba support on your server and still want it to work with an AD, check your KTPASS version (working version ends with a ZERO. 5.2.3790.0 and is 80 kb.
slowe on Monday, November 26, 2007 at 7:57 am

Johan,

IIRC, there is a bug in the RTM version of ktpass.exe that always set the KVNO (Key Version Number) back to 1, even when it should have been incremented. You may have been running into KVNO mismatch problems, and reverting back to the RTM version of ktpass.exe solved it by resetting the KVNO back to 1.

You can check the key version number in the keytab using klist; in AD, you must use ADSI Edit (or a similar utility) to look at the msDS-KeyVersionNumber attribute.

Thanks for sharing your experience with us!
John G on Monday, December 10, 2007 at 7:56 pm

I have authentication working at a Unix level quite nicely but I am having trouble now trying to get samba to work. The smbd daemon dies with a Bus error and when I run it in debug it dies at this point:

Primary group is 0 and contains 0 supplementary groups
pdb_getsampwsid: Building guest account
store_gid_sid_cache: gid 60001 in cache -> S-1-5-21-3640025915-183999177-3362999327-120003
fetch gid from cache 60001 -> S-1-5-21-3640025915-183999177-3362999327-120003
pop_sec_ctx (0, 0) – sec_ctx_stack_ndx = 0
push_sec_ctx(0, 0) : sec_ctx_stack_ndx = 1
push_conn_ctx(0) : conn_ctx_stack_ndx = 0
setting sec ctx (0, 0) – sec_ctx_stack_ndx = 1
NT user token: (NULL)
UNIX token of user 0
Primary group is 0 and contains 0 supplementary groups
Bus Error(coredump)

If I remove ldap from nsswitch.conf it starts up without any problem.

I have tried Samba from but the stable and unstable branches of Blastwave.

This is probably something simple, but any pointers on where to look would be great.

Cheers
John
ktsiv on Tuesday, December 11, 2007 at 11:23 am

I have managed to integrate windows AD and Solaris 10. My AD users can ssh to the solaris machine. I have the following problem: users from Windows AD, cannot start a CDE or Java Desktop session: after login, the desktop simply restarts and put you to the initial login screen. Any suggestions?
slowe on Tuesday, December 11, 2007 at 6:43 pm

Ktsiv,

Are there any error messages or warnings being logged in the log files?
Lule Chen on Wednesday, December 12, 2007 at 11:29 am

Hi, on my solaris 10 box, why it does not recognize the command ldapclient? I checked the directory /usr/sfw/bin and there is no such file.
bash: ldapclient: command not found

I checked the package

# pkginfo -l SUNWtlsu
PKGINST: SUNWtlsu
NAME: Network Security Services Tools
CATEGORY: system
ARCH: sparc
VERSION: 3.9.5,REV=2005.01.14.17.27
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: Network Security Services
PSTAMP: wozzeck20060910205347
INSTDATE: Sep 05 2007 12:59
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 23 installed pathnames
3 shared pathnames
4 directories
18 executables
18425 blocks used (approx)

the related package is there. Do you know if I need to install other package?

Thanks,

Lule
Dave McKenzie on Wednesday, December 12, 2007 at 9:53 pm

Lule:

Try doing a find / -name ‘ldapclient’

It may have installed somewhere else, given that in your output you have “BASEDIR: /”

Cheers,
Dave
Lule Chen on Thursday, December 13, 2007 at 2:19 pm

Thanks, Dave. It’s installed on a different location. But whenever I run ldapclient I always get the following error:
Stopping nisd failed with (1)
Errors stopping network services.

I don’t have NIS enabled on the machine. Do you know how can I get around this problem?

Lule
shawn on Tuesday, December 18, 2007 at 11:51 am

Been away for a while, but still have the same issue, if anyone can help. Basically I have application accounts that need to remain local, but all users need to use AD. As is, I can only get either AD or local accounts to work, but not both together. Did I do something wrong here, or is this how it is for everyone. Is there a change I can make to pam.conf, to get this to work as needed. Thanks for any help…

Shawn
Josh on Thursday, December 27, 2007 at 5:44 pm

Hi Scott:

Thanks for the excellent resource. It’s been very helpful thus far.

The kerberos part seems to work since since when I use kinit “ADuser” and type in the correct password nothing comes back.

However, on the ldap client side I’m having a problem where running getent “ADuser” returns nothing. There aren’t any errors being written to the messages file either. Also, when I snoop the traffic while running getent I see the ldap client bind successfully to the AD domain controller, but the Solaris server still doesn’t seem to gather the user information.

I’m trying to set this up using the old method without samba currently to provide a bit more background info.

Did you ever run into an issue like this? Any thoughts or suggestions as to how I can determine the cause of the problem?

Thanks again for the excellent resource!

- Josh
Kristian Duus Ã˜stergaard on Thursday, January 3, 2008 at 9:26 am

Hi Scott,

I can see that I am not the only one having some issues with getent not returning all the necessary data.

When I use getent passwd or getent group I get the expected output no matter wether the user exists in files or the AD.

But if I use getent passwd or getent group I only get the users respectively groups specified in /etc/passwd and /etc/group.

Any ideas as to what I can do to debug this issue ?

PS. I’m using the SFU 3.5.

Regards
Kristian Duus Ã˜stergaard
Josh on Thursday, January 3, 2008 at 2:43 pm

I decided to attempt the newer method using samba to join the AD domain.

Some of my attribute mappings were wrong in my previous ldap client config, so I fixed those and could query AD accounts with Unix attributes without issue. ( Kristian you may want to validate your ldap client config mapping and make sure your nsswitch file is setup properly as fixing these worked for me )

Kerberos ticketing worked fine and installing samba and joining the domain went well too.

The only remaining issue I have is I cannot log into the Solaris system unless there is a entry in the shadow file with the AD user name. In fact this entry has been locked, but I can still login fine if the entry is there.

Example:

jalb:*LK*:::::::

If that entry is not there I can only su as the AD user as root.

Has anyone seen this issue before? Thanks for your help!

- Josh
shawn on Thursday, January 3, 2008 at 3:54 pm

Scott or anyone else that may have seen this as well, I have yet another issue where I am randomly not able to logon to servers via AD. I can’t seem to find the culprit, and the issue somehow corrects itself over time, for reasons unknown. It has happened on Solaris 9 and Solaris 10 clients. Below is the error received when an ssh logon is attempted and denied.

Jan 3 11:28:03 krond sshd[13593]: libsldap: Status: 7 Mesg: Session error no available conn.

The last time this happened, I restarted nscd and was able to login. I am not certain if this corrected it or was just a coincidence, as it has not happened again for me to test. If anyone has any insight, please share.

Thanks,
Shawn
slowe on Thursday, January 3, 2008 at 8:53 pm

Shawn,

Some others have reported issues with NSCD (or NSS_LDAP) opening too many connections to the Active Directory domain controllers and getting an error similar to what you’re describing. We haven’t yet found a fix but, like you, restarting NSCD seems to fix the problem–but only for a while.

If anyone has any more information to share, please do!
Kristian Duus Ã˜stergaard on Friday, January 4, 2008 at 10:58 am

Hi Josh,

I can see that a filter has removed part of my explanation of the problem.

What I can do is ie.
getent group batchgrp
batchgrp::10005:maestro3,maestro2
Which is as expected.

But if I just do
getent group

I only get the groups defined in /etc/group and not a combined list of groups from /etc/group and AD.

So I think I have a very large portion correct but either there’s something wrong in the version of getent that I have (I’m hoping). Or I’ve done something wrong.

Either way someone with a better understanding of how getent gets it’s result might point me to where to look first.

Regards
Kristian
shawn on Friday, January 4, 2008 at 11:21 am

Thank you for confirming Scott, I had the issue again this morning, and did nothing but restart NSCD, and this cleared up the problem. What is strange is that when it occurs, it doesn’t affect everyone or every server either. There seems to be just a couple of servers facing the issue, 2 are Solaris 9 and one is Solaris 10. All have current patches, and the exact same config files for AD authentication (except for pam.conf on the Solaris 9 servers). For now I have just disabled NSCD on the affected servers, band-aid solutions rule… Hopefully someone much smarter than I, will eventually figure out the problem so I can just patch the servers later on. My servers don’t have a lot of logins, so I doubt I will see a performance hit anyway. Thanks again..

Shawn
Josh on Friday, January 4, 2008 at 12:15 pm

Kristian,

You’re seeing the same behavior I see when I use getent to query password or group entries without looking for a specific user or group. In this case only local accounts and groups are returned.

However, I can query specific AD groups and users fine and they can login to the Solaris system as long as there is an entry in the shadow file as I mentioned in my last post.

If anyone has run into this issue or has any suggestions I would greatly appreciate it. I can’t put an entry in the shadow file for every AD user – that pretty much defeats the purpose of the integration

Thanks,

Josh
chamilton on Sunday, January 6, 2008 at 4:52 pm

Has anyone had any luck with Solaris 10 8/07′s (update 4)included samba and joining an ad domain. From what i’ve read it is supposed to work but have yet to try it.
neville on Tuesday, January 15, 2008 at 11:46 am

hello

Can you remind me where your AD samba home directory mounting instructions are located.

I have AD working but now meed to mount the users homedirectory on a solaris system.

I remember you doiung something about this but cannot seem to find it now.

P.S thanks for a very usefull site.

neville
slowe on Tuesday, January 15, 2008 at 4:41 pm

Chamilton,

I have a system running Sol10 U4, but haven’t had the opportunity to test the included version of Samba.

Neville,

I think what you are looking for can be found here:

http://blog.scottlowe.org/2006/11/21/greater-ad-integration-via-nfs-and-automounts/

Thanks!
shawn on Thursday, January 17, 2008 at 4:57 pm

I seem to be back here posting for help every week or two, and usually find a solution or workaround shortly after, so I’ll give it a shot again. I have one solaris 10 server that just doesn’t want to use kerberos. I used the same script I wrote to deploy all of the files and configure the server for AD authentication, but for some reason this one server will not prompt for a kerberos password. I can browse active directory just fine, and getent returns data if I query for a user that isn’t in the passwd or shadow file. All other servers, if I attempt to logon, prompt me for my kerberos password, but this one server just says the usual keyboard-interactive authentication message. Has anyone seen this, or have any suggestions to remedy.

Thanks,
Shawn