Single signon with Kerberos options/direction

[Rob McShinsky]

I was wondering if anyone knows or has any contacts to anyone that may have
integrated a secondary Kerberos realm into their Active Directory Domain.
Here at Dartmouth Hitchcock Medical Center I am heading the option of Single
sign-on with many of our major applications. The factors I am faced with,
are below:

A. 2 Large Accounts Directories. - Active Directory and a homegrown User
Directory based on Oracle.
B. 1 MIT v4 KDC (Controls Kerberos Authentication to our Clinical
Information System and Mail Client). Could be upgraded to v5.
C. Microsoft KDC (Controls Authentication to our Windows Domain services.)

The Current working Definition of what we want to happen is below:
....We need to be able to have either a shared external KDC that our Windows
Domain 2000/XP, other down-level clients, and other non-Microsoft operating
system or non-domain clients can use seamlessly.

OR

....We need to have 2 KDC's. One for our Windows Domain 2000/XP clients and
one for other down-level clients, and other non-Microsoft operating system
or non-domain clients. The two tickets need to be an either or option. We
realize if this were the path, NT clients on the domain may have two logons.
We would prefer the first option, but facts are a little fuzzy right now,
hence why I am contacting you to see if you have any knowledge or any
contacts at Microsoft, or know of any clients that have done similar
approaches. We would like this to be a Server Centric design and not client
centric like many of the products out there now.

We have much more detail on this, but instead giving you the full project
plan in and email, maybe this can get the ball rolling.
Thanks for any help or direction to someone that may be able to help.

Robert B. McShinsky Jr.
Dartmouth Hitchcock Medical Center
1 Medical Center Drive
Lebanon, NH 03756
Windows Server Administration
603.650.5543

 

[Joe Richards [MVP]]

You know that your non-MS clients can use the MS KDC correct?

 

[ROB]

Yes I do. The main goal is to allow users in both directories with multiple
different OS to use a common kerb ticket with a serverside solution which
would then be able to be integrated in our applications which would bring us
closer to single sign on. If anyone has any thoughts or knowledge of some
of the process plaese let me know.

Robert B. McShinsky Jr.
Dartmouth Hitchcock Medical Center
1 Medical Center Drive
Lebanon, NH 03756
Windows Server Administration
(e-mail address removed)

 

[Joe Richards [MVP]]

You should be able to set up a realm trust on the MS side to trust the MIT
kerb realm through domain.msc.

Single signon is generally a little easier to manage when you use a single
authentication system and then tie all of the other systems to that
authentication system. Keeping everything working from two different
authentication systems may be quite a challenge. Try to pick one and
collapse the other into it.

 

[Rob McShinsky]

To solve the multiple Directory, we were looking at using the MIT kerb realm
referencing a consolidated LDAP Database (possibley ADAM, or IPlanet), which
we would use MIIS to create the consolidated DB from our current AD and
Oracle authenitcation databases.

Rob McShinsky

 

[Rob McShinsky]

Do you think that is a viable solution?

You should be able to set up a realm trust on the MS side to trust the MIT
kerb realm through domain.msc.

Single signon is generally a little easier to manage when you use a single
authentication system and then tie all of the other systems to that
authentication system. Keeping everything working from two different
authentication systems may be quite a challenge. Try to pick one and
collapse the other into it.

--
www.joeware.net


bring option.

 

[Joe Richards [MVP]]

That should work. I have seen quite a bit of chatter on the web (newsgroups
web sites etc) over the last couple of years of schools using Windows
clients against MIT Realms. Not sure how involved it would be as I haven't
done it. Also note that if you use GPO's etc, all of that would die without
AD.