remote printing/drive mapping to windows ad with mit kerberos

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

remote printing/drive mapping to windows ad with mit kerberos

David Botsch
Hi. We have successfully set up cross realm login to our windows active domain
where a user logs in as [hidden email] ... 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
[hidden email] -- 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 [hidden email]@MIT.KERB.REALM, and then either:
1. does a second AS request for this same tgt or
2. does a TGS request for cifs/[hidden email]

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
[hidden email]
********************************
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-3
David Botsch wrote:

> Hi. We have successfully set up cross realm login to our windows active domain
> where a user logs in as [hidden email] ... 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
> [hidden email] -- 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 [hidden email]@MIT.KERB.REALM, and then either:
> 1. does a second AS request for this same tgt or
> 2. does a TGS request for cifs/[hidden email]
>
> 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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos