Foreign Principal Mapping

[Benjamin Bennett]

Hi Eric,
   Shortly after setting foreign to true in source/smbd/sesssetup.c 
there is the following:
	pw = Get_Pwnam(user);
         if (!pw && !foreign) {
                 pw = Get_Pwnam(client);
                 SAFE_FREE(user);
                 user = smb_xstrdup(client);
         }

    So in your case what is happening is this:
     A) UREL\user lookup doesn't succeed.
     B) foreign is false so realm is disregarded and there's a lookup of 
user.

    The client already has the service tkt from the dc before this is 
happening (that's where the username is coming from). So basically, by 
forcing foreign to be false, you're just ignoring the realm of the user 
principal and a lookup for an identical local username is done.

    The difference between your method and mine is that with yours, 
joe at ANYWHERE will always be considered joe at NTDOM as long as they have a 
valid service tkt. No lookup of altSecurityIdentities is done here, 
except for the PAC data in the service tkt.
    With my method, a search is done in AD for a matching 
altSecurityIdentities. If there is a match, it will change the original 
user principal to the matching user's userPrincipal, and set foreign to 
false (since it is now a local domain account). If there is not a match, 
things keep going as normal. This allows the usernames to differ between 
realms, and also respects the original realm while looking up that 
mapping (so it must be user at UREL instead of user at ANYWHERE).

--ben

Eric Horst wrote:
>>   This is a patch which will allow a samba system acting as a Win2k
>>domain member to use the kerberos user mappings in AD.
>>
>>   So, say you have a samba box as a member of the Win2k domain 'MS'.
>>That domain trusts the kerberos realm 'MIT'. If you present a tkt as
>>joe at MIT to the samba system, it will lookup a matching
>>altSecurityIdentities attribute in AD for the MS domain, and if found
>>you are now joe.schmoe at MS or whatever account it got matched to.
> 
> 
> I was working on the same issue and have it working without your big
> patch.  Let me describe what I saw and how I changed the behaviour.
> 
> I have a Samba box as member of the Windows domain 'NDOM'.  That domain
> trusts the kerberos realm 'UREL'.  A client computer is member of Windows
> domain 'NDOM'.  Log in to client computer as user at UREL.  Accessing Windows
> shares works.  Accessing Samba shares don't.  Error log:
> 
> smbd/sesssetup.c:reply_spnego_kerberos(178)  Ticket name is [user at UREL]
> smbd/sesssetup.c:reply_spnego_kerberos(190)  Ticket for foreign realm
> user at UREL smbd/sesssetup.c:reply_spnego_kerberos(218)  Username UREL\user is invalid on this system
> smbd/error.c:error_packet(94) error string = No such file or directory
> 
> Now, to test (using brute force) I simply went into sesssetup.c and
> changed line 196 to read 'foreign = False;' to force it to never consider
> the ticket foreign.  Now I can access Samba shares using the UREL ticket.
> 
> So what is happening?  It appears that if I force Samba to not consider
> the ticket foreign then it will forward the ticket along to the NDOM DC.
> The NDOM DC must look at the foreign ticket, the altSecurityIdentity, and
> decide that it looks OK and issues the cifs ticket.
> 
> My problem is solved.  However, is modifying Samba to not refuse foreign
> realm tickets the right solution?  Is your mapping solution better?  In
> some ways it seems that your patch is simply duplicating what the NDOM DC
> is doing automatically.
> 
> Does any of this make any sense?  I'm slowly getting up to speed on this
> Kerberos stuff.
> 
> --Eric
>