[OT]: Externalized KDC ...

[C.Lee Taylor]

Greetings ...

	Luke, thank you for your responce ...

	A few questions, and maybe I should explain why I was looking at this ... First, we are
trying to bring our Linux ( OpenLDAP ) and AD users together and use one password.  Now I know
that we could use winbind and friends to do this or I could create a trust between my 
Linux domain and AD domain, which I have tested both ways, but my problem is that we have a few sites
which need auth that are not directory connected to my network ( WAN ), and some times these links go down.
Now if I use winbind and kerberos inside AD, my remote users can't auth, and then there systems go down.

	Now when I saw a message in samba-tech about using an external KDC, I throught that maybe I
could put my Kerberos inside my OpenLDAP and replicated that to my remote sites ( which I do with Linux users )
and get AD to use the same Kerberos details.  I currently create accounts in both system and don't mind to
continue to do, if my users can use one password and username.

	But, you say that we would need something to create NTLM auth.  If this was ignored, what would we loose?
Things like Win9X?  Could we not find a simple way to put in NTLM through the web or something?  Any ideas would be
great.

Thanks
Mailed
Lee



> Generally there are two choices: individual workstations can use
> an external KDC for authentication, with the proviso that users
> must have local accounts; or you can setup a cross-realm trust
> between an Active Directory domain and a "MIT" Kerberos realm,
> with the proviso that MIT accounts must be duplicated in Active
> Directory. In either case you need some sort of password
> synchronization in order for downlevel (NTLM) authentication to
> work.
>
>("MIT" in this case is Microsoft-speak for non-Active Directory
>Kerberos. You could of course use Heimdal or CyberSafe.)

>>    A little while ago, I saw chatter about Win2K server using an 
>>external KDC, is there any more information that any body could point me 
>>at ...