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
-
As expected, shortly after posting here, I figured out my issue. My kerberos libraries were a different version than what was installed on all other servers it seems. I checked the package versions and they reported the same, but the file sizes were off by a bit. In case anyone else faces this same issue, here are the file sizes for comparison. The .before.AD files, are the originals.
ls -l /usr/lib/security | grep pam_krb5.so.1
lrwxrwxrwx 1 root root 15 Jul 6 2007 pam_krb5.so -> ./pam_krb5.so.1
-rwxr-xr-x 1 root bin 102692 Jan 17 20:52 pam_krb5.so.1
-rwxr-xr-x 1 root bin 94920 May 29 2007 pam_krb5.so.1.before_ADls -l /usr/lib/security/sparcv9 | grep pam_krb5.so.1
lrwxrwxrwx 1 root root 15 Jul 6 2007 pam_krb5.so -> ./pam_krb5.so.1
-rwxr-xr-x 1 root bin 109840 Jan 17 20:52 pam_krb5.so.1
-rwxr-xr-x 1 root bin 109680 May 29 2007 pam_krb5.so.1.before_AD -
Shawn,
Any idea why the file sizes were off? Did you just copy the files from a working server in order to make it work?
-
Hi Scott,
Is there a way to restrict users from accessing some servers, but allowing them access to others?
It seems once the unix user attributes are set on the DC the user can login to any system as long as the user has a unix primary group(AD security group).
Any thoughts for controlling user access at the AD or Solaris system level?
Thanks for your help.
- Josh
-
Hi Scott,
Not sure why the libraries were different, I have seen quite a few little issues here and there, and have been under the gun to get this rolled out ASAP, so unfortunately once I figure out how to fix it, I move on. Maybe down the road I’ll go back and look, but that probably won’t be for some time. I still have a couple little issues I have not been able to figure out or find info on, but they are not show stoppers at this time. Just in case anyone has a solution, here are the anomalies I have in my env:
1. when sudo is called, users ticket cache file in /tmp becomes owned by root.
2. solaris 9, sudo entries prompt for password, but any thing entered as password is accepted (this has to be a pam.conf mistake, I just don’t see it yet).
3. NSCD causing login issues. Disabling NSCD was a fix at first, but on some oracle servers, any attempt to start up a listener process, results in a hung session. Enable NSCD, issue is gone, disable it again and it’s back.
I can’t explain how helpful this site was for me, just want to say thanks for the hundredth time.
-
Scott, are you aware of any easy way to prevent specific users from accessing certain servers in Solaris? I saw your write up on Linux, but have you messed with a Solaris solution as well (since linux and default solaris pam are not equal).
-
I was able to find a pam module to accomplish what I need to restrict certain users from logging in. If anyone else needs the same, I used pam_listfile. I grabbed Linux-PAM-0.81.tar.bz2 (the same tarball I downloaded for the pam_mkhomedir module), and compiled just the pam_listfile module. As with so much of my testing, this partially gets me what I need, but does not work completely as expected. For some reason if I use item=user and create a list of users, it works fine, but if I try to use item=group, to deny a whole group, all logins bomb out. If anyone else happens to use this module and gets the item=group flag to work, please let me know if you used any specific flags at compile time.
-
Josh – one idea I came up with (if you have a small number of machines or groups of machines) is to create a symlink such as /bin/productionsh to /bin/sh on only the production machines, then if a user is allowed only production access, set their shell to /bin/productionsh. This of course would end up quite complex when different users need different things, but it’s still an idea…
Anyone else want to comment on this setup, or have any ideas that could help?
-
Dave, I outlined how I got around this issues, right above your post. Using pam_listfile, you can just create a list of users you want to deny access to the server. You can configure it to allow only certain users as well, if you have a server that should only have a very limited number of users. There are a few other config options as well. I was unable to get this to work using groups, but had no issue using user id’s.
-
Scott or anyone else, is there anything that needs to be done, to get GSSAPI authentication to work with this setup. Any gotchas that were found? For the life or me, I just can not make any headway. I can login to all servers just fine, but am always prompted for a password. Was there any config changes made to suns sshd_config, or ssh_config? I’ve tried different cryptos and ptypes when generating the keytab with ktpass, I’ve tried using computer and user accounts in AD, and several other things with no luck. If it helps at all, here are my pam.conf sshd-gssapi entries, courtesy of Douglas Engert:
sshd-gssapi auth required pam_authtok_get.so.1
sshd-gssapi auth optional pam_dhkeys.so.1
sshd-gssapi auth sufficient pam_krb5.so.1
sshd-gssapi auth sufficient pam_unix_auth.so.1
sshd-gssapi account requisite pam_roles.so.1
sshd-gssapi account sufficient pam_unix_account.so.1
sshd-gssapi account sufficient pam_krb5.so.1
sshd-gssapi session sufficient pam_unix_session.so.1
sshd-gssapi session sufficient pam_krb5.so.1I’ve tried debugging sshd, so if anyone is willing to look, I can paste the contents.
TIA for any help…
-
In case anyone is still out there, and willing to assist, here are the debug entries for sshd, when GSSAPI fails.
debug1: userauth-request for user testuser service ssh-connection method gssapi-keyex
debug1: attempt 1 initial attempt 0 failures 1 initial failures 0
debug2: input_userauth_request: try method gssapi-keyex
debug2: Mapping initiator GSS-API principal to local username
debug2: Mapped the initiator to: testuser
debug2: Starting PAM service sshd-gssapi for method gssapi-keyex
debug3: Trying to reverse map address 192.168.240.57.
Failed gssapi-keyex for testuser from 192.168.240.57 port 37614 ssh2
debug1: userauth-request for user testuser service ssh-connection method gssapi-with-mic
debug1: attempt 2 initial attempt 0 failures 2 initial failures 0
debug2: input_userauth_request: try method gssapi-with-mic
debug1: Client offered gssapi userauth with { 1 2 840 113554 1 2 2 } (supported)
debug1: Received delegated GSS credentials
debug2: Mapping initiator GSS-API principal to local username
debug2: Mapped the initiator to: testuser
debug2: Starting PAM service sshd-gssapi for method gssapi-with-mic
Failed gssapi-with-mic for testuser from 192.168.240.57 port 37614 ssh2
debug1: userauth-request for user testuser service ssh-connection method publickeyIt then moves on to public key and keyboard interactive. I can enter the AD password and login just fine, but for some reason, GSSAPI fails.
-
I can’t get it to work.
The LDAP search works but there always appear the following lines:
Fortsetzungsreferenz(en) ohne Anschluss:
ldap://ForestDnsZones.ADSTEST.DE/DC=ForestDnsZones,DC=ADSTEST,DC=DE
Fortsetzungsreferenz(en) ohne Anschluss:
ldap://DomainDnsZones.ADSTEST.DE/DC=DomainDnsZones,DC=ADSTEST,DC=DE
Fortsetzungsreferenz(en) ohne Anschluss:
ldap://ADSTEST.DE/CN=Configuration,DC=ADSTEST,DC=DEI can’t also see the userPassword attribute and wonder why.
Here is the output of an example ldapsearch query:
[root@SOLTEST ~]# ldapsearch -h 192.168.33.1 -p 389 -s sub -b dc=ADSTEST,dc=de -D cn=proxyUser,cn=Users,dc=ADSTEST,dc=de -x -w pr0xyUser cn=proxyUser
version: 1
dn: CN=proxyUser,CN=Users,DC=ADSTEST,DC=DE
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: proxyUser
sn: proxyUser
description: Benutzer zur Anbindung der Unix und Linux Systeme
givenName: proxyUser
distinguishedName: CN=proxyUser,CN=Users,DC=ADSTEST,DC=DE
instanceType: 4
whenCreated: 20080320152703.0Z
whenChanged: 20080320170928.0Z
displayName: proxyUser
uSNCreated: 24661
uSNChanged: 24681
name: proxyUser
objectGUID:: 5Z9QxgLYPUaALtSkgHXKYw==
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 128505013107343750
lastLogoff: 0
lastLogon: 128505013893750000
pwdLastSet: 128505013852187500
primaryGroupID: 513
userParameters:: bTogICAgICAgICAgICAgICAgICAgIGQJICAgICAgICAgICAgICAgICAgICAg
ICAg
objectSid:: AQUAAAAAAAUVAAAAqthgVzZ8eDALSeAWYAQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: proxyUser
sAMAccountType: 805306368
userPrincipalName: proxyUser@ADSTEST.DE
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ADSTEST,DC=DE
msNPAllowDialin: TRUE
uid: proxyUser
msSFU30Name: proxyUser
msSFU30NisDomain: ADSTEST
uidNumber: 501
gidNumber: 500
unixHomeDirectory: /home/proxyUser
loginShell: /bin/sh
Fortsetzungsreferenz(en) ohne Anschluss:
ldap://ForestDnsZones.ADSTEST.DE/DC=ForestDnsZones,DC=ADSTEST,DC=DE
Fortsetzungsreferenz(en) ohne Anschluss:
ldap://DomainDnsZones.ADSTEST.DE/DC=DomainDnsZones,DC=ADSTEST,DC=DE
Fortsetzungsreferenz(en) ohne Anschluss:
ldap://ADSTEST.DE/CN=Configuration,DC=ADSTEST,DC=DE
[root@SOLTEST ~]#Any suggestions?
-
It’s me again:
Another strange thing:
If I execute “getent passwd” I get:
[root@SOLTEST ~]# getent passwd
root:x:0:0:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
gdm:x:50:50:GDM Reserved UID:/:
webservd:x:80:80:WebServer Reserved UID:/:
postgres:x:90:90:PostgreSQL Reserved UID:/:/usr/bin/pfksh
svctag:x:95:12:Service Tag UID:/:
nobody:x:60001:60001:NFS Anonymous Access User:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:
dts:x:0:0:DTS_USER_MIT_ROOTRECHTEN:/export/home/dts:/bin/bash
service:x:100:1:SERVICE_USER:/export/home/service:/bin/sh
demouser:x:500:1004:Example Demo User:/usr/demouser:/bin/sh
[root@SOLTEST ~]#There are no ADS Users visible, but if I give the name of an ADS User as key, then I get this:
[root@SOLTEST ~]# getent passwd proxyUser
proxyUser:x:501:500:proxyUser:/home/proxyUser:/bin/sh
[root@SOLTEST ~]#How can that be?
I’d like to see all users, ADS and local users with the getent command. Is that possible? -
OK, now I got it!
Nick, Tim,
if you have installed the support tools (they are locaten on the w2k3 CD at SUPPORT\TOOLS) you can run the adsiedit.msc. Expand the “Domain” Container. In the following tree right-click on your group and open the “properties”. At the “Attribute Editor” Tab select msSFU30MemberUid and click “Edit”. Add as Values the usernames of all Users you want to add to the group (Attation: Case-sensitive”. For exmple add “demouser”. Save with “OK” and leave the tool.
Add the attribute “attributeMap=group:memberuid=msSFU30MemberUid” to your ldapclient command. Now the groups will be shown correctly.
Life becomes easier if you simply use a script for user and group creation.Another important thing I figured out:
If want to use a DNS Server different from the Domain Controller, or none, you should add the attribute “followReferrals=false” to your ldapclient command. Otherwise it can happen, that you can’t see a single user or group at the Solaris system.I hope this will help a little bit…
@slowe: Thank you for your articles. They helped very much!
-
…and why do not start the “winbind” service directly on the Solaris 10 update 4 and above directly?
# svcadm enable winbind samba
-
I’m getting a few errors on Samba Version 3.0.23b when doing a net ads join -U david, below is a snippet of a testjoin -d10:
[2008/04/09 15:57:14, 10] libsmb/namequery.c:(408)
remove_duplicate_addrs2: looking for duplicate address/port pairs
[2008/04/09 15:57:14, 4] libsmb/namequery.c:(1502)
get_dc_list: returning 1 ip addresses in an ordered list
[2008/04/09 15:57:14, 4] libsmb/namequery.c:(1503)
get_dc_list: xxx.xxx.xx.xx:389
[2008/04/09 15:57:14, 5] libads/ldap.c:(127)
ads_try_connect: sending CLDAP request to xxx.xxx.xx.xx (realm: CSUMAIN.xxx.xxx.xx)
[2008/04/09 15:57:14, 10] libsmb/namequery.c:(71)
saf_store: domain = [CSUMAIN], server = [137.166.69.52], expire = [1207721534]
[2008/04/09 15:57:14, 10] lib/gencache.c:(131)
Adding cache entry with key = SAF/DOMAIN/CSUMAIN; value = xxx.xxx.xx.xx and timeout = Wed Apr 9 16:12:14 2008
(900 seconds ahead)
[2008/04/09 15:57:14, 3] libads/ldap.c:(287)
Connected to LDAP server xxx.xxx.xx.xx
[2008/04/09 15:57:14, 0] utils/net_ads.c:(281)
ads_connect: Operations error
Join to domain is not valid
[2008/04/09 15:57:14, 2] utils/net.c:(988)
return code = -1Any ideas?
Thanks,
Dave -
Ok, got past that problem by adding the “followReferrals=false” listed earlier in the comments (we run separate DNS.)
Now I’m able to join the domain, do a kinit and a getent fine, but when I try to su or ssh, doesn’t let me. Snippet of /var/adm/messages:
Apr 9 16:52:16 eddie sshd[747]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos database
Apr 9 16:52:25 eddie su: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos database
Apr 9 16:52:25 eddie su: [ID 810491 auth.crit] ‘su dmckunix’ failed for root on /dev/pts/1
Apr 9 16:53:13 eddie sshd[752]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos database
Apr 9 16:53:45 eddie sshd[760]: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos database
Apr 9 16:53:49 eddie last message repeated 1 time
Apr 9 16:53:57 eddie su: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: Server not found in Kerberos database
Apr 9 16:53:57 eddie su: [ID 810491 auth.crit] ‘su david’ failed for root on /dev/pts/1Thanks once again for all your help
-
The saga continues… fixed the previous error by editing kdc.conf to reflect the correct domain in the realm section, and also changing the resolv.conf to reflect the active directory domain as the first entry in the search path (there are many search domains for legacy reasons in our setup.)
And here’s the new error:
Apr 10 13:16:16 eddie su: [ID 537602 auth.error] PAM-KRB5 (auth): krb5_verify_init_creds failed: New password cannot be zero length
My investigations pointed to it being an issue with the version of Windows ktpass executable being under 2003, but all the servers are 2003… will be continuing to investigate, but if anyone has any feedback it’s much appreciated.
-
Ah, got past that by using a valid group (oops!)
Now I’m able to login, but get:
“You are not authorized to access this server”
Tried changing to a few different shells, added the group into the /etc/groups file just for kicks, and checked the sshd_config file and can’t see anything that might be restricting logins. I have a feeling that it might be in pam or something like that, but have no idea where to start…
-
Once again I’ve solved all my problems by sleeping on it and approaching it with a little common sense.
This one is something that no Google could have fixed – in our organisation someone had written a custom /etc/profiles that would check the group membership against a hardcoded list. Get rid of that and it works perfectly.
Thanks once again for a wonderful article!
-
Oops, I posted to the wrong thread. Please move it to a more appropriate one. My apologies.
-
Stephen,
I’ve moved your question over to the Linux-AD version 4 article. Thanks for commenting!
-
Hi Fregge,
I can see you have the same issue with getent passwd only returns the local users and not the AD users.
Did you solve it ? if yes how
Regards
Kristian -
I can confirm that the version of Samba shipped with newer Solaris 10 releases can in fact join an AD domain, and can save a keytab, similar to the blastwave version.
-
following up on Fregge’s comment about supplementary groups. It does resolve the problem if you are in a Solaris only environment. But what I noticed was that if I update the groups for a user via the AD Users and Groups admin tool (for my linux side), it wipes out the MemberUid field in the LDAP tree. Atleast this is what happened to me. So what I did was to create a new attribute in the AD tree via the MMC snap-in under the msSFU30 OID tree. (follow the Schmmgmt snap-in instructions on this link http://technet2.microsoft.com/windowsserver/en/library/3c14aa51-9761-4568-9519-8f37d4fbaa661033.mspx?mfr=true)
Once you have the snapin, you can add an attribute, I named mine msSFUMemberSolaris, make sure its in the msSFU OID tree, to make life simple. Then expand the Classes tree, go down to group-> click on it, go to the right hand side where it has all of its attributes, right click, go down to properties, Attributes tab, click in the Optional box, Add button, go down and select your new attribute. close.
Make sure you change your ldapclient config from
attributeMap=group:memberuid=msSFU30MemberUid
to
attributeMap=group:memberuid=msSFU30MemberSolaris
or whatever you have, then follow Fregge’s instructions on how to add users via ADSIedit. -
Scott,
Thanks for posting this stuff online, information elsewhere is incomplete at beast. I was able to use your instructions to get my RHEL 5.2 servers integrated into AD. The only problems I had were a couple loose screws behind the keyboard.
However, I am having a heck of a time trying to get Solaris 10 to work. The Kerberos setup was pretty easy, LDAP on the other hand is throwing me for a loop. I ran ldapclient manual the way you suggested, I changed the site specific information.I give the command: getent passwd username
The error I get back in /var/adm/messages is:
hostname nscd [ID 545954 user.error] libsldap makeConnection failed to open connection to ForestDNSZone EXAMPLE.COMAny ideas?
I tried turning nscd off, didn’t work. I got the same error above except the log replaces nscd with getent. -
Tony,
Can you share your ldapclient configuration?
-
I dont mean to be difficult but do you mean what I typed or the output of
#ldapclient listIf you mean what I typed I promise it is exactly what your wrote above except I added a -v in the begining which helped me troubleshoot. Apparently Solaris doesnt like a space in the canonical name of the proxy account, RHEL doesnt mind though. I made the site specific changes though.
If you mean the output of ldapclient list I will have to hand jam the info in, my server is not connected to the Internet.
I ran verbose snooping on my solaris server and found that it is trying to resolve “forestdnszone.my.domain” and that is what is failing. I’m starting to think it could be my Windows DNS setup.
Thanks for the quick reply by the way.
-
Tony,
I was actually thinking of the output of the “ldapclient list” command, if that’s not too much trouble. Feel free to sanitize domain names and such to protect the innocent.
-
Hi there,
for me the supplementary group problem also still persists, maybe someone can provide a valid ldap configuration here.
Another thing regarding this is that my default id command does not even show supplementary groups, so i have to use the id from /usr/xpg4/id:
-bash-3.00# id
uid=0(root) gid=0(root)
-bash-3.00# /usr/xpg4/bin/id
uid=0(root) gid=0(root) groups=1(other),2(bin),3(sys),4(adm),5(uucp),6(mail),7(tty),8(lp),9(nuucp),12(daemon)
-bash-3.00# uname -a
SunOS xx-yyyyzz-xxxxx 5.10 Generic_137112-01 i86pc i386 i86pcMaybe that clears it a little bit!
cheers Kai
-
Here it is:
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_BINDDN= cn=LDAP Account,cn=users,dc=xx,dc=xxx
NS_LDAP_BINDPASSWD= ENCRYPTED PASSWD
NS_LDAP_SERVERS= 10.X.X.X
NS_LDAP_SEARCH_BASEDN= dc=XX,dc=XXX
NS_LDAP_AUTH= simple
NS_LDAP_CACHETTL= 0
NS_LDAP_CREDENTIAL_LEVEL= proxy
NS_LDAP_SERVICE_SEARCH_DESC= passwd:dc=xx,dc=xxx?sub
NS_LDAP_SERVICE_SEARCH_DESC= group:dc=xx,dc=xxx?sub
NS_LDAP_ATTRIBUTEMAP= group:userpassword=userPassword
NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid
NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn
NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber
NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=homeDirectory
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=user -
Hi all,
Please i need help i have windows 2003 SP2 using SFU3.5 and Solaris 10.My question is how can i allow all OUs(All domain Users) through ldapclient i explain
i have 50 plus ous in my Windows AD server.it is created by script so i need to allow all domain users in ldapclient not restrict on OU base.So again i ask how can access all Domain user on solaris using ldapclient.Here is my example i created on UNIX-OU Ou all user which is in this OU are authenticated but when i created new OU nd add user it is not authenticate.
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=test,cn=users,dc=mani,dc=com \
-a proxyPassword=Admin123 \
-a defaultSearchBase=dc=mani,dc=com \
-a domainName=mani.com \
-a “defaultServerList=192.168.1.89″ \
-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=UNIX-OU?sub \
-a serviceSearchDescriptor=group:ou=UNIX-OUsub—————————————————
bash-3.00# ldaplist -l passwd test01
dn: CN=test01,OU=UNIX-Users,OU=UNIX-OU,DC=mani,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: posixAccount
cn: test01
givenName: test01
distinguishedName: CN=test01,OU=UNIX-Users,OU=UNIX-OU,DC=mani,DC=com
instanceType: 4
whenCreated: 20080818130558.0Z
whenChanged: 20080818131916.0Z
displayName: test01
uSNCreated: 106727
uSNChanged: 106757
name: test01
objectGUID: ÿÁï,:$N¾
userAccountControl: 66048
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 128635396771562500
pwdLastSet: 128635383582812500
primaryGroupID: 513
objectSid:
PuTTY accountExpires: 9223372036854775807
logonCount: 1
uid: test01
sAMAccountType: 805306368
userPrincipalName: test01@mani.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=mani,DC=com
msSFU30Name: test01
uidnumber: 10047
gidnumber: 10044
loginshell: /bin/sh
msSFU30Password: ABCD!efgh12345$67890
msSFU30NisDomain: mani
homedirectory: /home/test01
msSFU30PosixMemberOf: CN=tstgrp01,OU=UNIX-Group,OU=UNIX-OU,DC=mani,DC=com
bash-3.00# PuTTY
—————————————–
bash-3.00# getent passwd test01
test01:x:10047:10044::/home/test01:/bin/sh
bash-3.00#Thanks in Advance
Hayat
-
Hayat,
Change the serviceSearchDescriptor lines in your LDAP configuration to point to the base of the domain (dc=mani,dc=com) instead of a specific OU. That should fix your problem.
-
Scott,
I figured out the LDAP problem. It looks as though my Solaris server was looking for a couple of DNS records: ForestDnsZones & DomainDnsZones. I looked on my DNS server, they werent there, I recreated the records on the DNS server but that didn’t work. I hard coded the records it was looking for in the Solaris server’s hosts file, kinda ghetto but it worked. The problem I’m having now is, I think, related to Samba and keytab creation.
The version of Samba I’m trying to use comes with the newest release of Solaris 10, and the net command supports the ads option. Running net ads join creates a machine account in AD.
Is the “net ads join” supposed to create the keytab on the Solaris server? I’m still a little confused with the keytab and what it is used for. -
I check but still no luck please can you change the line for me
for pointing the domain my domain is mani.com-a serviceSearchDescriptor=passwd:ou=UNIX-OU?sub \
-a serviceSearchDescriptor=group:ou=UNIX-OUsub -
Hi slowe,
Still no luckldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=test,cn=users,dc=mani,dc=com \
-a proxyPassword=Admin123 \
-a defaultSearchBase=dc=mani,dc=com \
-a domainName=mani.com \
-a “defaultServerList=192.168.1.89″ \
-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:dc=mani,dc=com? \
-a serviceSearchDescriptor=group:dc=mani,dc=com?“newall.sh” 26 lines, 1104 characters
bash-3.00#
bash-3.00# sh newall.sh
System successfully configured
bash-3.00# cp /opt/nsswitch.conf /etc
bash-3.00# id test
id: invalid user name: “test”
bash-3.00# id test01
id: invalid user name: “test01″
bash-3.00#Please help Thanks
Hayat -
Hayat,
Try this:
-a serviceSearchDescriptor=passwd:dc=mani,dc=com?sub \
-a serviceSearchDescriptor=group:dc=mani,dc=com?subSee if that helps. Good luck!
-
Hi Scott -
I’ve been excited by the possibilities of Single Sign On and *NIX/AD integration since I first learned that Micro$oft had elected to implement LDAP and Kerberos. Fantastic to see the state of the technology on this so far along now.
You have performed quite a service to the tech community by pulling all this together, thank you.
Can you or anyone here give us all a sense of what the sizes are of the environments where *NIX/AD integration is being used?
How many *NIX systems?
How many users?What *NIX variants have been successfully integrated besides Solaris & Linux? HP-UX? AIX? *BSD?
How about if we all agree to keep our organizations anonymous, but some quantification of where we are all at would be great.
Thank you all for working to move the world forward.
Warm regards,
Bart
-
Thank you so much slowe,
it is working fine but i have one more question i have one parent domain and 4 child domain.my all parent dc users are working fine my question is how can add my all child domain nd how can assign the unix attributes for child and how can use remot NIS server as PDC please help.mean i need to authenticate all domain users (parnet domain,child domain users) throgh sun box1 using ldap if you have any sample EXample?any sugguation for that??
Thanks Again for great help
Regards
Hayat -
Hayat,
AFAIK, you can’t authenticate against multiple AD domains.
-
I am working on the same issue as Hayat – trying to authenticate members of multiple domains to the same UNIX server. Of course we are having some issues, but we are still working through it and if we find a cmoplete solution I will post here again. But my question is regarding your sample krb5.conf file.
You have multiple domains listed in the realms section
[domain_realm]
.example.com = EXAMPLE.COM
.subdomain.example.com = EXAMPLE.COM
Which would seem to indicate that both users from example.com and subdomain.example.com should be able to authenticate. Is this the case in your testing, or were you testing strictly against a single domain structure?I know in LDAP is we actually had UNIX hosts acting ad KDC’s we can do cross realm authentication (both heirarchical and non) but as of yet, since the AD servers act as the KDC’s and trust is setup within AD, we have not been able to find a definitive answer.
The only thing we can think of, and we will be trying today, is to create the machine in both domains and merge the keytabs so that the machine essentially exists in both domains.
Oh yes, of course we have to use the GC port (3268) and there was a specific patch level we had to be on for the follow referrers for the GC port to work, but that is as far as we have gotten so far. Any ideas are welcome.
Thanks
-
Dstan,
The domain_realm section isn’t about multiple AD domains, it’s about multiple DNS domains, and mapping those DNS domains to the corresponding Kerberos realm (or AD domain). In the example configuration, systems from both the example.com and subdomain.example.com DNS domains will authenticate against the EXAMPLE.COM Kerberos realm (or AD domain). I haven’t found a way to authenticate against multiple AD domains, although I’m sure there is a way.
Good luck!
-
Tony,
I had the same problem – ForestDnsZones.xxxxx.xxx did not resolve. It seems I had forgotten to add the adequate ‘dns’ entries in ‘nsswitch.conf’ after running the ‘ldapclient’ utility…
——————
hosts files dns
——————//Henrik
-
Hello,
Some body know how to debug the pam_mkhomedir.so for Solaris?
I followed this http://www.keutel.de/pam_mkhomedir/index.html to compile the pam_mkhomedir.so and the compilation is fine
I put this line into /etc/pam.conf :
other session required pam_mkhomedir.so.1 skel=/etc/skel umask=0022 debugBut nothing work. The user of openldap base can logon but no directory create. Is it normal ? How can i debug it ?
Thanks by advance for you answer. -
Hello Scott. I’m having some issues that I’m hoping you can help me with. Everything works great with the exception of two things.
1) Solaris isn’t recognizing groups. If I run ‘id’ on a user, it only shows their primary group. The mappings are correct.2) One particular user, we’ll call him foo, is unrecognizable by Solaris. If I run ‘id’ on foo, it returns:
id: invalid user name: foo
The same user works great on my linux ldap/kerberos implementation and ALL other users work fine on Solaris.I’m not sure how to go about debugging these. Here’s my ldapclient command:
ldapclient manual \
-a credentialLevel=proxy \
-a authenticationMethod=simple \
-a proxyDN=cn=,cn=Users,dc=lightningsource,dc=com \
-a proxyPassword= \
-a defaultSearchBase=dc=lightningsource,dc=com \
-a domainName=lightningsource.com \
-a “defaultServerList=172.24.XX.XX” \
-a attributeMap=group:userpassword=userPassword \
-a attributeMap=group:memberuid=memberUid \
-a attributeMap=group:uniquemember=member \
-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:cn=Users,dc=lightningsource,dc=com?sub \
-a serviceSearchDescriptor=group:cn=Users,dc=lightningsource,dc=com?subHere’s my nsswitch.conf:
#
# Copyright 2006 Sun Microsystems, Inc. All rights reserved.
# Use is subject to license terms.
#
# ident “@(#)nsswitch.ldap 1.10 06/05/03 SMI”#
# /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: files dns# Note that IPv4 addresses are searched for in all of the ipnodes databases
# before searching the hosts databases.
ipnodes: files dnsnetworks: ldap [NOTFOUND=return] files
protocols: ldap [NOTFOUND=return] files
rpc: ldap [NOTFOUND=return] files
ethers: ldap [NOTFOUND=return] files
netmasks: ldap [NOTFOUND=return] files
bootparams: ldap [NOTFOUND=return] files
publickey: ldap [NOTFOUND=return] filesnetgroup: ldap
automount: files ldap
aliases: files ldap# for efficient getservbyname() avoid ldap
services: files ldapprinters: user files ldap
auth_attr: files ldap
prof_attr: files ldapproject: files ldap
tnrhtp: files ldap
tnrhdb: files ldapHere’s my krb5.conf:
[libdefaults]
default_realm = LIGHTNINGSOURCE.COM
verify_ap_req_nofail = false[realms]
LIGHTNINGSOURCE.COM = {
kdc = lvdc03.lightningsource.com
kdc = lvdc02.lightningsource.com
kdc = lvdc01.lightningsource.com
admin_server = lvdc03.lightningsource.com
}[domain_realm]
.lightningsource.com = LIGHTNINGSOURCE.COM[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used# frequently.period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, …)
version = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}Any help would be appreciated
-
Carl,
We really need to see what’s in your log files when these things happen. Can you send me an e-mail with that information? Thanks!
-
Note for Solaris 10: if the loginShell attribute does not have a value, the graphical login program dtgreet dumps core.
-
For multiple domains to work we use the UPN for login – so that everyone has to login using username@DOMAIN – it’s not the best solution but it works.
-
Hi, Josh
“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”
Now, I have the same problem.
Can you share which attribute mappings errors?Thanks. -
Can somebody explain how to get secondary groups issue solved, please share the ldapclient file, thanks in advance
-
Hi Scott,
Thank you for your very helpful articles.
I’m coming back with a question about supplementary groups.
I’m using schema extensions provided by Windows Server 2003 R2.
All group memberships work fine when I configure ldapclient with the following mappings:
NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid
NS_LDAP_ATTRIBUTEMAP= group:uniquemember=member
This makes it necessary to administer two attributes in AD.
In my Linux environment this is not necessary. The Linux LDAP client supports RF2307bis and follows the DN in member attribute to get the uid from the user entry.
I tried to invalidate the memberuid Attribute in Solaris by
NS_LDAP_ATTRIBUTEMAP= group:memberuid=noSuchAttribute
But this didn’t help.Is it possible to activate this RF2307bis support also in Solaris-LDAP?
Thanks
Heiner
‹ Previous · 1 · 2 · 3 · 4 · Next ›
Site Sponsors
155 comments
Comments feed for this article
Trackback link: http://blog.scottlowe.org/2007/04/25/solaris-10-ad-integration-version-3/trackback/