From: Adams, Jonathan K. [C] (Jonathan.K.Adams@nga.mil)
Date: Mon Mar 21 2005 - 08:21:14 EST
Thanks to Paul Roetman, Alan Pae, Mike Salehi and E Gold (didn't catch your
name)
One suggestion is to use MS Windows Services for Unix, which is a good
option for some networks, but not for mine because of certain security
constraints, as well as the need for an independant unix kerberos realm
Another suggestion was Vintela, which is great, but we were looking to do
this without purchasing a third party solution - actually we would probably
have gone with this, if we were unable to solve this internally
To clarify the situation:
We want to do single sign-on for a Unix Network with cross-realm
authentication to a windows network AD/Win 2K. Of course the cross realm
authentication issue is related to SEAM and there is much documentation
covering how to do this. Where we hit the wall was using Sun One DS to
store usernames, uid, gid auto_home (authorization) information, and using
SEAM / Kerberos - GSSAPI for authentication...
I found a sun document which describes the process nicely... Hopefully this
will clear things up for others who emailed me having similar issues as
well...
http://docs.sun.com/source/816-6698-10/contents.html
particularly chapter 11 - looking under GSSAPI Indentity mapping
(http://docs.sun.com/source/816-6698-10/ssl.html#16652) shows the following
excerpt:
GSSAPI Identity Mappings
Identity mappings for SASL mechanisms try to match credentials of the SASL
identity with a user entry in the directory. See "Identity Mapping"
<ssl.html> for complete description of this mechanism. Authentication will
fail if the mapping cannot find a DN that corresponds to the SASL identity.
The SASL identity is a string called the Principal that represents a user in
a format specific to each mechanism. In Kerberos using GSSAPI, the Principal
is an identity with the format uid[/instance][@realm], where the uid may
contain an optional instance identifier followed by an optional realm that
is often a domain name. For example, the following are all valid user
Principals:
bjensen
bjensen/Sales
bjensen@EXAMPLE.COM
bjensen/Sales@EXAMPLE.COM
Initially, there are no GSSAPI mappings defined in the directory. You should
define a default mapping and any custom mappings you need according to how
your clients define the Principal they use.
To define identity mappings for GSSAPI:
Create new mapping entries under cn=GSSAPI,cn=identity mapping,
cn=config. See "Identity Mapping" <ssl.html> for the definition of the
attributes in an identity mapping entry.
Examples of GSSAPI mappings are located in the following
file:
ServerRoot/slapd-serverID/ldif/identityMapping_Examples.ldif
The default GSSAPI mapping suggested in this file assumes
that the Principal contains only a user ID, and this determines a user in a
fixed branch of the directory:
dn: cn=default,cn=GSSAPI,cn=identity
mapping,cn=config
objectclass: dsIdentityMapping
objectclass: nsContainer
objectclass: top
cn: default
dsMappedDN:
uid=${Principal},ou=people,dc=example,dc=com
Another example in this file shows how to determine the user
ID when it is contained in a Principal that includes a known Realm.
dn: cn=same_realm,cn=GSSAPI,cn=identity
mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: same_realm
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@example.com
dsMappedDN: uid=$1,ou=people,dc=example,dc=com
Restart the Directory Server for your new mappings to take effect.
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
This archive was generated by hypermail 2.1.7 : Wed Apr 09 2008 - 23:30:24 EDT