samba - Oct 2002 - Username map and UNIX UID assignments - my findings

Background:

I'm trying to make sure my Unix and NT users are being assigned the correct
UID from both platforms so they own files correctly from both sides.  I was
hoping to avoid username maps since our users with cross platform access
already have matching usernames on both sides (or will when we reconfigure).
I've been playing with several parameters,  and fixed some things,  but I
did have to use a username map. 

Some interesting tidbits:

1.  I originally used "winbind use default domain = yes" in 2.2.3a to
get my
NT usernames to automatically map to the corresponding UNIX username without
requiring a username map.  This parameter seems to have no affect on
username mapping in 2.2.5 with respect to the UID assignment.  

2. I had to change my winbind separator to "_" (underscore) because
"+"
seemed to be interfering adversely with NIS.  

3 Without a username map file,  I wasn't getting assigned the correct UNIX
UID,  so we tried using one,  but the syntax a colleague used: 

	karen = karen
	(unix)   (NT)

wasn't quite working as we expected.   My UNIX login directory (HOMES) still
doesn't get shared automatically,  and I can't get the correct
permissions
to change/write in areas where  karen has access on the UNIX side.  I can,
however,  create files in a share that has the following settings:

	read only = yes
	write list = @"WALNETNT_Domain Users"

So karen (NT) is correctly identified as a member of the "WALNET_Domain
Users" group,  and can write in areas where write access is granted to the
"WALNET_Domain Users" group.

If I create a file in that share via samba,  and look at it on the UNIX side
with 
  
	ls -l 

it looks like the files are owned by karen,  however,  if I look at the
actual UID assigned to the file with  

	ls -n 

I see that UID assigned to the file is in the winbind range rather than my
normal UNIX UID,  and there lies the access discrepancy.  NT user karen (UID
10000) can't write in directories that UNIX user karen (UNIX, UID 7506)
owns.  A look at the samba client log files confirms that the UID assignment
is not correct.

	 
3. If I change the username.map entry to

	karen = WALNETNT_karen 

I am now being assigned the correct UNIX UID,  my home directory is
automatically made available (yey!) , and files I create from my PC via
samba are assigned the correct UNIX UID for karen (yey!),  and I can access
MOST of the same areas via samba that I can normally access on the UNIX
side, EXCEPT samba shares that grant  write permission based on a given
domain group membership (mumble...).   

An unexpected side effect of fixing the UID mapping was that the karen
account stopped being correctly identified as a member of the
"WALNET_Domain
Users" group,  so I can no longer write in the samba share directory  where

	read only = yes
	write list = @"WALNETNT_Domain Users"

This is a world writable directory on the UNIX side,  so karen can put stuff
in there from the UNIX side,  and should also be able to write in there from
the NT side)


SO .... 

Any idea how I can fix that last piece?   The idea on that particular share
was to have a drop box for all of our NT and UNIX domain users,  but not to
allow anyone else's domain users anything but read only access.  


	Thanks,

		Karen Wieprecht



-----Original Message-----
From: Gerald (Jerry) Carter [mailto:jerry@samba.org] 
Sent: Friday, October 18, 2002 10:32 AM
To: Wieprecht, Karen M.
Subject: RE: [Samba] Username map and UNIX UID assignments


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 18 Oct 2002, Wieprecht, Karen M. wrote:
> I tried a flavor of that,  but I was using quotes around the PC 
> username, and I was still using winbind use default domain = yes,  
> I'll try no quotes
You shoudl disable the "winbind use default domain" parameter.  It was
merged into the 2.2 only to makes merging easier from HEAD.  It was
documented by mistake.
> with the winbind parameter set both ways and see if I can get this 
> working. I'll let you know what happens if you are interested.
Would be good to know if the workaround is successful.



jerry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE9sBtGIR7qMdg1EfYRArZBAJ9nN6bOBEcTW0sL2zW3NfnyJ4AMEgCghLs9
ffjRsTpE+5IIeWzSBU+I4cQ=4Dlv
-----END PGP SIGNATURE-----