John H Terpstra wrote:
You do not need to configure local users on a Samba domain member server,
winbind is the best tool for such interoperability. Use of winbind will
ensure unified user and group identities for MS Windows users.
There is fair amount of users that use both Windows and UNIX, so it is easier for us to have every user account in both environments. This is also the reason why accounts have to match.
There is a set of users common to the NT domain and the UNIX NIS
environment. That is the usernames are the same in both. Yes, Samba is a
domain member (security = domain), so the passwords for these users are
verified against the NT domain.
My question was: Did you add local users on the Samba server into the /etc/passwd database?
Actually most of the users are in NIS. Assuming Samba is using standard libraries they are undistinguishable from /etc/passwd users.
There I am a little unfirm. As far as I know it is an AD domain that
still supports NT style authentication.
If your Win2K domain is Active Directory based then you should configure
Samba-3 as an ADS member server. See chapter 7.4 of the
Samba-HOWTO-Collection.
Ok I will try that.
I do not want to see on the UNIX side any UIDs that are not listed in
/etc/passwd. I do not want to differentiate between NT domain users and
matching users in /etc/passwd.
Why do you need user entries in /etc/passwd? Let NSS do that for you from
the Windows Active Directory - gives more controlable results.
I am afraid this is not an option. We do not want Samba to dictate the way the whole environment is architectured. There are number of reasons why we do not want to do that.
2. If UNIX accounts generally are not related to domain accounts, why do
I get "proper" mapping from my NT username to the same UNIX username
(unless I want ACLs!) and more importantly to the right user id? I do
not have to run winbindd for that!
Explained above.
Ok, let me give you an example scenario. Please bear with me.
I have a Samba server with the security=domain. I have users "joe" (uid=1001) and "fred" (uid=1002) in the passwd file on the Samba box. Just because they log in to it using ssh and run sparc compiler all the time. No, I can not just put them into AD and use winbindd, there are tons of reasons for that (example -- I can not convert a thousand workstations some of which are very ancient to this scheme).
I have also got users "DOMAIN\joe" and "DOMAIN\fred" and they map a share from that server. When these two create files from the Windows side they get "fred" (1001) and "joe" (1002) as UNIX owners and everybody is happy.
Now they want to use ACLs. So the "DOMAIN\joe" does right mouse click and adds "DOMAIN\fred" into the ACLs of a file he just created. My "joe" is smart enough to see, that he can only add "DOMAIN\fred" which is different from "SAMBA\fred" who supposedly owns the file, but there is nothing he can do about it, Windows would not let him use "SAMBA\fred" anyway.
Joe also reasonably believes that, since their Windows domain accounts have always been properly mapped into their UNIX accounts, the same machinery would work this time.
Well, at this point winbindd maps "DOMAIN\fred" into UNIX uid 40002 and adds ACL for 40002 to the file. Then "fred" opens a shell session and tries to vi the file. What happens? Correct -- "permission denied".
So. Is there a way out of this without switching "joe" and "fred" to using nss_winbind and NT authentication pam module? In other words, can I get this to work wihtout converting "fred" and "joe" to using Windows domain accounts on UNIX machines? And without switching their UNIX UIDs to 40001 and 40002?
The Adobe PDF is a little easier to navigate. The book "The Official Samba-3 HOWTO and REference Guide" has a useful subject index in the back (7 pages!) that makes things much easier to find. It's available from Amazon.
I hope this helps you, as well as the next person who wants to sort out
this type of problem.
Please bear with me, I am not there yet. Thanks very much for your help!
--
Anton Solovyev
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
