> Heh I cut this... but a lot of what you were saying while somewhat >correct was misleading. Active Directory can work fine in a Unix > environment. A lot of folks do it. I do. In fact setting up Active > directory to authenticate off kerb5 and hand out kerb5 tgts. Same goes > for sub services... you can totally use bind9 in tandem with active > directory.
> The sketchy area is a unified directory service. Maybe someone else has > better info than I. We currently maintain both Active directory and an > openldap server in our environment. I'd be interested in hearing what > others have done to unify their directory services between windows and > unix environments. > But as far as synchronizing unix and windows authentication... kerberos > works dandy in both areas. =D > Being able to do GSSAPI-wit-mit authentication to servers with my active > directory given MIT tgts... is just plain cool. We're both correct and both misleading - all depends if you're trying to integrate UNIX into a Microsoft infrastructure or Microsoft into a UNIX Infrastructure how much is and is not possible. Also integration is different (in my mind) from interoperation e.g. you have a UNIX infrastructure, and a Windows infrastructure both of which are aware and talk to one another, perhaps even use occasional services from one or the other. I think the real problem as demonstrated by the original poster is the assumption that because something says it complies with standards it is therefore equal to all other things that claim compliance with the same standard. Therefore, Microsoft Active directory is Kerberos and LDAP so therefore is exactly the same as OpenLDAP + MIT Kerberos, or SunONE + SEAM, etc, etc. The standards (say as defined in RFCs) can have a fairly broad interpretation. This problem is then compounded when Marketing types use standard compliance as a vehicle for flogging their products (without any real understanding and whether they really do comply or not) By the sound of it your windows workstations will still be authenticating against an AD server (which just happens to get it's tickets from a non M$ KDC). The M$ AD Server will be adding all the extra "glue" required by the windows workstations. Basically you still need a true blue microsoft AD server to provide AD user authentication (along with all the other benefits of AD i.e. management) to yourWindows workstations. If one uses a non-M$ authentication source e.g. Samba or local workstation accounts mapped to non-M$ KDC principals then you loose all the really nice features of AD. All you have is a centralised authentication source. In the case of principal mapping it's too much of a pain to do on a large scale and as for Samba I'm pretty sure it is still largely based on the old NT4 domain logic (it can integrate into a M$ AD environment by acting as a member server: not replace it or replicate it) so it will only take a M$ patch or update to remove/break backwards compatibility with NT4 to knacker up Samba as a [complete] M$ server replacement option. I couldn't blame M$ it must be horrible having to drag around compatibility with 10 year-old software. So I'm sorry if I implied that there was no way for M$ and non-M$ products to interoperate or that integration was wholly impossible. It can work to varying degrees, depending on what you want to do and what limitations you wish to accept. However, with respect to the original poster I stand by my statement that there is absolutely no way to use non-M$ i.e. opensource products to replace/replicate the full functionality of a true-blue M$ AD Server. Yeah you can use bits'n'bobs but when it comes down to it you still need to pay M$ mucho-money for a server. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
