remote printing/drive mapping to windows ad with mit kerberos - Kerberos

This is a discussion on remote printing/drive mapping to windows ad with mit kerberos - Kerberos ; Hi. We have successfully set up cross realm login to our windows active domain where a user logs in as user@MIT.KERBEROS.REAL M ... this works fine if the user is logging onto the console of a Windows machine in the ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: remote printing/drive mapping to windows ad with mit kerberos

  1. remote printing/drive mapping to windows ad with mit kerberos

    Hi. We have successfully set up cross realm login to our windows active domain
    where a user logs in as user@MIT.KERBEROS.REALM ... this works fine if the user
    is logging onto the console of a Windows machine in the domain.

    However, if a user has his own machine, not in the windows active directory
    domain, things do not work. So, the scenario is this:

    a user needs to map a windows printer share or a drive share, authenticating as
    user@MIT.KERBEROS.REALM -- any thoughts on how to make this work?

    >From what we can tell, the windows client (we have been testing with XP SP2)

    requests the krbtgt@MIT.KERB.REALM@MIT.KERB.REALM, and then either:
    1. does a second AS request for this same tgt or
    2. does a TGS request for cifs/windows-2003-server-fqdn@MIT.KERB.REALM

    in the case of 1, after the two successful AS requests, nothing else happens
    in the case of 2, this fails, of course, because the principal does not exist
    in the MIT kerberos db. Ok, so adding this princiapl to the MIT kerberos db is
    easy enough. But, there seems to be no documentation on how to then add this
    same principal to Windows with the same kvno/password.

    But, as I said, sometimes 1 happens, and sometimes 2 happens.

    I was expecting this to work the same, of course, as machines in the domain.
    That is, obtain krbtgt/MITREALM@MITREALM, use this to do a TGS req for
    krbtgt/WIN.AD.REALM@MITREALM, and then present this.

    Any thoughts here?

    Thanks!



    --
    ********************************
    David William Botsch
    Consultant/Advisor II
    CCMR Computing Facility
    dwb7@ccmr.cornell.edu
    ********************************
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: remote printing/drive mapping to windows ad with mit kerberos

    David Botsch wrote:

    > Hi. We have successfully set up cross realm login to our windows active domain
    > where a user logs in as user@MIT.KERBEROS.REALM ... this works fine if the user
    > is logging onto the console of a Windows machine in the domain.
    >
    > However, if a user has his own machine, not in the windows active directory
    > domain, things do not work. So, the scenario is this:
    >
    > a user needs to map a windows printer share or a drive share, authenticating as
    > user@MIT.KERBEROS.REALM -- any thoughts on how to make this work?
    >
    >>From what we can tell, the windows client (we have been testing with XP SP2)

    > requests the krbtgt@MIT.KERB.REALM@MIT.KERB.REALM, and then either:
    > 1. does a second AS request for this same tgt or
    > 2. does a TGS request for cifs/windows-2003-server-fqdn@MIT.KERB.REALM
    >
    > in the case of 1, after the two successful AS requests, nothing else happens
    > in the case of 2, this fails, of course, because the principal does not exist
    > in the MIT kerberos db. Ok, so adding this princiapl to the MIT kerberos db is
    > easy enough. But, there seems to be no documentation on how to then add this
    > same principal to Windows with the same kvno/password.
    >
    > But, as I said, sometimes 1 happens, and sometimes 2 happens.
    >
    > I was expecting this to work the same, of course, as machines in the domain.
    > That is, obtain krbtgt/MITREALM@MITREALM, use this to do a TGS req for
    > krbtgt/WIN.AD.REALM@MITREALM, and then present this.
    >
    > Any thoughts here?
    >
    > Thanks!


    The home workstation is not joined to the WIN.AD.REALM. Therefore, the
    workstation has no knowledge that the cifs/windows-2003-server-fqdn
    service exists in the WIN.AD.REALM domain. XP relies on a KDC
    belonging to the joined domain to tell it where the service is located.
    If there is no joined domain, it can rely on a KDC belonging to the
    realm associated with the logon principal. The mechanism by which the
    KDC informs the client of the location of a service is by a "referral".
    The MIT KDC does not support this functionality. One option you have
    is to allow your users to join their machines to the WIN.AD.REALM.

    Jeffrey Altman


    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

+ Reply to Thread