On Tue, Jan 06, 2009 at 06:43:20AM +0100, Christian Perrier wrote:
> Well, from what I see, it is absolutely confirmed that you reach the
> share as user joy and the last line of the log confirms that.
>
> It is then more and more likely that this falls down in the category
> of several bugs related to "valid users" handling between 3.0.23 and
> 3.0.25.
>
> The right confirmation can only come by testing with a more recent
> version (such as a backported 3.2: I will maybe finally provide one as
> we unofficially provide backported 3.2.x, with x>5 for lenny,
> already).
>
> Of course, I understand that upgrading a PDC might be somewhat tricky
> for you. Can't you duplicate the PDC configuration to a test machine
> that could run lenny or unstable?
In the meantime I upgraded the entire domain to the new lenny Samba - it was
painful in the process because the old 3.0 servers started somehow applying
new access logic towards the first 3.2 BDC and users complained about not
being able to access. The new Samba, however, had considerably more useful
logs and based on reading them I think I found the original problem:
My users had something like this in LDAP:
dn: cn=Pero Peric,ou=users,dc=imago,dc=hr
uid: pperic
sambaSID: S-1-5-21-145766654-2861277506-3272706772-
sambaPrimaryGroupSID: S-1-5-21-145766654-2861277506-3272706772-513
As it turns out, this was a blatant lack of understanding of what the
sambaSID field is supposed to be - a unique identifier of the *user* object,
*NOT* simply a pointer to the unique identifier of the domain object.
This faulty mapping seemed to cause the Samba servers to think that all
users had all the privileges of the root object, probably related to the
fact that I had a cn=root user in LDAP with sambaSID
S-1-5-21-145766654-2861277506-3272706772-0 - I no longer have the exact
logs to demonstrate, sorry. In particular this new debugging helped me:
[2009/06/12 10:48:43, 3] lib/util_seaccess.c:se_access_check(252)
se_access_check: user sid is S-1-5-21-145766654-2861277506-3272706772-1001000
se_access_check: also S-1-22-2-1000
se_access_check: also S-1-1-0
se_access_check: also S-1-5-2
se_access_check: also S-1-5-11
se_access_check: also S-1-22-2-4
se_access_check: also S-1-22-2-20
se_access_check: also S-1-22-2-24
se_access_check: also S-1-22-2-25
se_access_check: also S-1-22-2-29
se_access_check: also S-1-22-2-40
se_access_check: also S-1-22-2-44
se_access_check: also S-1-22-2-46
se_access_check: also S-1-22-2-100
se_access_check: also S-1-22-2-2000
(This is from a current, fixed session... hopefully! :)
The origin of this mistake was in the blatant inadequacy of the Samba
documentation. After some more Googling, I found this very helpful page:
https://people.chem.umass.edu/wiki/index.php?title=LDAP_Schema_and_Fields
>From there I was able to infer exactly where my LDAP data was faulty,
and what I needed to fix in order to get Samba working properly.
Now I rechecked the official HOWTO, and I see something like that in
chapter 11 "Account Information Databases", section "Password Backends -
ldapsam". This absolutely needs to be better integrated. For example,
the chapter 4 "Domain Control" has very few references to LDAP at all;
the chapter 5 "Backup Domain Control" surprisingly does have a few
references to LDAP (which are out of place, really), but no actual links
to the ldapsam description in chapter 11.
So in conclusion, for this bug to be properly closed, I think it would be
good to have two things:
* more explicit warnings in code that interprets sambaSID entries
in order to help debug broken ldapsam backends
* more cross-references between the documentation sections in order
to help the reader in actually finding the proper information
If you still want to close this bug, please do open a new one for these
important unresolved issues.
I'm also going to file two other related bug reports against 3.2 now,
but considerably less severe than this one :)
--
2. That which causes joy or happiness.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
