Using kerberos w/o binding to active directory

[Douglas E. Engert]

David Carlin wrote:
> I have a file server on the campus active directory that contains the 
> home directories for all the users of campus computer lab.  I would like 
> for students to be able to connect to a share and access their files 
> from their dorm PCs not on the active directory.  The complication here 
> is since their dorm PCs are not bound to the active directory, they are 
> not using Kerberos for authentication.  I'd like to come up with a set 
> of instructions so they can get a Kerberos ticket and connect to the 
> share, but I don't have a strong Kerberos background.
> 

See:
http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp


> I have been able to do this on a mac by setting up an appropriate 
> /Library/Preferences/edu.mit.kerberos file (just like krb5.conf) and 
> using the /System/Library/CoreServices/Kerberos application to get a 
> ticket.  Once this happens, the Mac user is able to connect to the share 
> and see their files.  This at least leads me to believe what I want to 
> accomplish is possible.
> 
> Berkeley has a set of instructions for their students to do this.  Their 
> AD also uses Kerberos for authentication:
> 
> http://calnetad.berkeley.edu/documentation/interoperability/#item1
> 
> It seems to have the students install a .reg file which has the same 
> effect as running the neccessary ksetup.exe commands.  I have tried 
> using this method to no avail - creating an analogous registry file by 
> copying those keys from a working machine on the active directory.
> 
> The difference in the event logs on the server side between the failed 
> windows connections and the successful MacOS 10.3 ones are this:
> 
> Successful Network Logon:
>    User Name:  djc6
>    Domain:     ADS
>    Logon ID:      (0x0,0x64EC9)
>    Logon Type: 3
>    Logon Process: Kerberos
>    Authentication Package: Kerberos
> 
> Login Failures all show:
>    Logon Process: NtLmSsp
>    Authentication Package: NTLM
> 
> So it seems I am missing something fundamental where the windows clients 
> aren't even trying to use Kerberos for authentication.
>

Yes, the machine normally must also have a Kerberos host principal, which
can be in a MIT based realm using cross realm. The user can then log in
using user at REALM which will get the TGT for the user and a host/hostname at REALM
ticket to authenticate to the machine. Most likely the machine is not registered.

If you login locally, the runas command can do something
similar, but it requires a host/hostname ticket in the process.

But the runas /netonly can also be used, and does NOT require
the host to be registered in a realm.  (The difference has to do with
access to the local machine.)

For example in a cmd window on w2k where I have logged in as a local user:

   runas /netonly /user:myusername at ANL.GOV cmd
    This prompts for the password.

will open up another cmd window with a title of
cmd (running as myusername at ANL.GOV)

Using the klist from the Windows resource kit in this window
shows no tickets.

Running:

  net use P: \\mywindowsserver\myusername$

will give my access to my domain home directory and
will get me some tickets as shown by the Windows klist:

C:\WINNT\system32>klist tickets

Cached Tickets: (2)

    Server: krbtgt/ANL.GOV at ANL.GOV
       KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
       End Time: 2/17/2005 2:41:15
       Renew Time: 2/23/2005 16:41:15


    Server: HOST/mywindowsserver at ANL.GOV
       KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
       End Time: 2/17/2005 2:41:15
       Renew Time: 2/23/2005 16:41:15

I can only access P: from this window or any application
started in this window.  But it does show a way to use
only the Microsoft Kerberos from a machine not in
any domain or realm to access resources in a domain if the
user has a domain account.

The difference between what Windows and the MAC is doing may
have to do with access to the local machine's file systems.
The runas /netuser is more like with the MAC may be doing.

P.S. These test where run on a machine that is registered
in a Kerberos realm but this should not have any effect.
(Try it on your own machine.)











> Anyone have any ideas?
> 
>    -David
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444