sorry for being pretty much OT with this... OT for the list and even
OT for the current subject...

* Dustin Puryear <[EMAIL PROTECTED]> [2007-02-02 16:01]:
> As far as I know, you can't "integrate" AD into another
> authentication source directly. AD is the authentication source, as
> far as Microsoft is concerned.

I certainly didn't expect them to make it easy.
authenticating M$ Windows clients via unix kerberos at least seems to
be possible[1]. but I'm just the directory guy (and unix, email,.. ;)
trying to reduce dependencies on and password transfers to certain
other systems.

> That said, most of us have to support large environments with
> multiple LDAP sources, password files, etc. Generally, there will be
> some kind of synchronization, somewhere.

we have developed custom tools to do this (and much more). the problem
is that syncing credentials is actually a lot easier than messing with
these systems to integrate cleanly with existing infrastructures.
(thank goodness our password policy is still not finished ;)
  but it's yet another system that wants to be the authoritative
source for authN (opendirectory, active directory, etc.).

some WebSSO systems seem to have features (at least CAS has a PAM
module; there's some mentioning of CoSign PAM but no sign of code)
that let them venture into the realms (no pun intended) of
kerberos. while this won't help with integrating M$ desktops it would
help with unix/linux/osx maschines and even the occational webmail
system (alleviating the need for proxy authN/n-tier authN).

maybe I should just get stop looking for reasons not to deploy
kerberos and go for it? ;)

regards,
-p.schober

[1] using AD in cross-realm trust with AuthN via some linux KDC or
    using ksetup for standalone PCs like mentioned here
    http://sial.org/howto/kerberos/windows/


---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the 
SUBJECT of the message.

Reply via email to