SUMMARY: single sign on question

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