Installed Kerberos, and now?

[hairydamon@hotmail.com]

> 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.