map_username() inconsistencies [was Re: [Samba] Re: ADS valid users can't map share]

[Luke Mewburn]

On Wed, Oct 20, 2004 at 09:21:09PM -0500, Gerald (Jerry) Carter wrote:
  | I've done some more digging and the username map stuff is a little
  | worse than I initially thought.
  | 
  | (a) when 'security = user', the username map is applied before 
  |     the password is checked is checked.
  | (b) when 'security = ads', the username map is applied to 
  |     fully qualified names (domain\user) after the krb5 ticket
  |     is checked.  (see the next comment for NTLM).
  | (c) when 'security = domain' (or NTLM auth for ADS security),
  |     the username map is applied to the login name only.  The original
  |     domain\user is still authenticated but the UNIX identify
  |     is looked up in the username map.
  | 
  | So I guess that the cleanest way to fix this is to apply the username
  | map before checking authentication when validating user locally 
  | and apply it after authentication for domain users (krb5 & ntlm).
  | 
  | How do people feel about this?

We need to fix it and document that security={domain,ads} requires
the leading "DOMAIN\" in `username map' and `admin users';
I got bitten by this recently (trying to map "DOMAIN\administrator"
to root AKA uid==0).

There's a related issue though.  Right now, it's hard to support:
	* ADS for authentication
	* NIS for username<->UID mapping (or another nsswitch.conf source)
	* winbindd for IDmap faked UIDs as a fallback for people not in NIS.
	* nsswitch.conf  passwd: files nis winbind
because it appears that smbd looks up DOMAIN\user, gets a miss in NIS
(via getpwnam(3)) and then winbindd fakes up a UID _before_ smbd gets a
chance to try getpwnam(3) on the name with the leading "DOMAIN\"
stripped.  Is there a workaround for this configuration?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba/attachments/20041021/3582b360/attachment.bin