ktpass.exe -princ boxname.domain.com@DOMAIN.COM -mapus
er service.svc -crypto des-cbc-md5 +DesOnly -pass password -kvno 19 -ptype KRB5_NT_PRINCIPAL -out keytab.keytab
Targeting domain controller: domaincontroller.domain.com
Failed to set property “servicePrincipalName” to “boxname.domain.com” on Dn “CN=service.svc,OU=ServiceAccounts,D
C=Domain1,DC=Domain2,DC=com”: 0×13.
WARNING: Unable to set SPN mapping data.
If service.svc already has an SPN mapping installed for boxname.domain.com, this is no cause for concern.
Key created.
Output keytab to keytab.keytab:
Keytab version: 0×502
keysize 75 boxname.domain.com@DOMAIN.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 19 etype 0×3 (DES-CBC-MD5)
keylength 8 (0×19624394c2434fb5)
Account service.svc has been set for DES-only encryption.

so, question: what is my best course of action from this point?

thanks

I haven’t run into any situations in which an ordinary user (UNIX-enabled or not) can’t be used as the proxy account for nss_ldap to lookup attributes. Then again, I haven’t done any testing on SBS, so it’s entirely possible that the permissions on the attributes is different. You might try granting the permission to read the UNIX attributes to your proxy account to see if that helps at all. Good luck, and keep us posted!

Situation: we’re running an SBS 2003 R2 domain with a member server (also a DC) that is Server 2003 x64 R2. The member server has Unix Id Management installed on it. Also installed on the primary DC (ie: SBS server) is the IDMU.EXE as described in ( http://support.microsoft.com/kb/921913 ) to ensure all the properties tabs are there (they are).

When we query the 2003 ldap database for unix attributes, they can only be seen if the user whose attributes we want to access is the one accessing LDAP, for example on the “Unix Attributes” tab we have setup information for home directories, uid, etc… on a user called test. If we use a LDAP browser and bind using the test user we can see the attributes, but if we bind using a generic user (as anticipated in just about every how-to we’ve come across), the unix attributes cannot be seen.

All of the recommendations for accessing unix attributes through LDAP, create a proxy user to access the attributes for authorization purposes, but if this proxy user cannot see the attributes, then obviously something is not working.

Any insight on how the permissions are supposed to be setup within AD to ensure LDAP bindings are successful??

Thanks!

A quick Google search should give you plenty of information on using BIND as your DNS for Active Directory. I personally haven’t had the opportunity to do it, so I can’t share any information with you. Likewise, a perusal of the Cisco web site or a Google search should turn up plenty of information on using RADIUS to handle PIX authentication. You can also refer to my article on PIX VPN integration with Active Directory (link above).

DNS - Runs on Linux
ADS - Windows 2000 or Windows 2003 - Pointing to Linux DNS (BIND 9)
Radius Authentication for Admins to access PIX and other network resources including Servers

- Could you please, guide me, if you have any resources.

Many thanks,

Suresh

Thanks!
Rob

I currently use NIS and I need to get my Solaris 8, 9 &10 machines to use AD for at least passwd, netgroup, group and my various automounter maps. At some point I would like to integrate my entire set of NIS maps, but the ones mentioned above are the most important.

I’ve seen, but have not tested, articles on setting up Solaris 9 and 10, but none for 8. My understanding of how PAM works is very limited, and I understand that PAM would play a major role here.

Can you, or someone else reading this, recommend what steps and software I would need to do this? Ideally, I would be talking to my AD server in using either SSL or like crypto solution.

Many thanks,

.vp

PS: I’ve looked at winbind and found that it would not work for ssh auth.