Installed Kerberos, and now? - Kerberos

This is a discussion on Installed Kerberos, and now? - Kerberos ; I am trying to create the same functionality as Windows Server offers, so I installed Kerberos. So, I have my Kerberos server running, how do I get my XP stations connect to it and set permissions?...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Installed Kerberos, and now?

  1. Installed Kerberos, and now?

    I am trying to create the same functionality as Windows Server offers, so I
    installed Kerberos. So, I have my Kerberos server running, how do I get my
    XP stations connect to it and set permissions?



  2. Re: Installed Kerberos, and now?

    You can't. Microsoft have proprietary extentions to Kerberos/LDAP etc
    that means its impossible to get a Microsoft product using a non-M$ KDC
    in the manner you (everyone) would like.

    There are some pretty horrible crappy ways of making a Windows
    workstation speak to a Non-M$ KDC but it's rubbish - basically involves
    setting up local accounts on your workstation and then mapping those
    local accounts onto kerberos principals in your non-M$ KDC. This might
    be OK as a silly toy exercise or as a vague justification for claiming
    your (M$) product is actually Kerberos compliant but if you've got any
    reasonable number of workstations (i.e. more than one) then it's a
    pain. There's an article in Techweb somewhere on the M$ website that
    explains how to do it - although I don't think the instructions they
    give actually work.

    You appear to be making the mistake many make of thinking that M$ AD is
    simply kerberos - it's not.

    Microsoft Active Directory is a propietary fusion on LDAP, Kerberos,
    DHCP and DDNS. There are enough extentions to the standards to make it
    absolutely impossible to get a M$ product speaking to a non M$ product.

    When M$ talk about interoperability they are actually talking about
    making non-M$ products talk to AD (prior to your eventualy migration to
    their fabulous product) not the other way around. For instance
    Microsoft want you controlling your UNIX workstations using AD prior to
    upgrading to Windows XP/2003/05/long horn/horn swaggler etc. AD will
    provide enough compliance with Kerberos and LDAP standards that a UNIX
    workstation would be able to use it as a source for account information
    (although you do have to extend your AD schema for it to work).

    In short what you are trying is impossible (that's why Bill is the
    richest man on earth). If you want Windows Server functionality to
    manage and control your windows workstations then you need a Windows
    Server running AD. M$ have made a very successful business out of
    locking customer in and keeping the competition out - if it was easy
    (or even possible) to replace a Windows AD server with (non M$)
    products then no doubt the M$ lawyers would be destroying people with
    billion dollar law suits.


  3. Re: Installed Kerberos, and now?

    hairydamon@hotmail.com wrote:
    > You can't. Microsoft have proprietary extentions to Kerberos/LDAP etc
    > that means its impossible to get a Microsoft product using a non-M$ KDC
    > in the manner you (everyone) would like.
    >
    > There are some pretty horrible crappy ways of making a Windows
    > workstation speak to a Non-M$ KDC but it's rubbish - basically involves
    > setting up local accounts on your workstation and then mapping those
    > local accounts onto kerberos principals in your non-M$ KDC. This might
    > be OK as a silly toy exercise or as a vague justification for claiming
    > your (M$) product is actually Kerberos compliant but if you've got any
    > reasonable number of workstations (i.e. more than one) then it's a
    > pain. There's an article in Techweb somewhere on the M$ website that
    > explains how to do it - although I don't think the instructions they
    > give actually work....

    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.

    --
    Best regards,

    Matthew Joyce System Administrator
    Tel: 212.871.1747 x329 Visual Trading Systems, LLC
    Mobile: 917.596.9619 mjoyce@vtsystems.com

    The information contained in this E-mail message is privileged,
    confidential, and maybe protected from disclosure; please be aware that
    any other use, printing, copying, disclosure or dissemination of this
    communication maybe subject to legal restrictions or sanctions. If you
    think that you received this E-mail message in error, please reply to
    the sender.

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: Installed Kerberos, and now?

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


+ Reply to Thread