On 23/03/12 23:03, Andrew Bartlett wrote:
On Sun, 2012-03-18 at 08:19 +0100, steve wrote:
Hi
There seems to be a discrepancy in the s4 schema concerning security groups.
Domain Users comes with gidNumber: 100. This is however contrary to what
the schema allows. You can show this as follows:
Steve,
Domain Users does not hold that attribute. There is an idmapping in
idmap.ldb for this value, but it is not placed in the directory by
default.
As you mention here, you could add it if you want to:
Create a new group. samba-tool group add mygroup.
Use phpldapadmin to add the gidNumber attribute.
There is an error because gidNumber is provided by the posixGroup class
and that objectclass is not present by default.
No problem. We add objectClass: posixGroup and then we can add
gidNumber: xxx just fine.
This however throws up another error in that mygroup is now not a
security group but a posix group and the ability to view and manipulate
group members is not available in Active Directory Computers and Users
(ADCU). We made the folllowing observations:
1. The members tabs are missing from mygroup properties in ADCU
2. you can still use samba-tool group addmembers to manipulate the groups
3. you can still select and change primary group for a user in ADCU
4. you can add users to the group under phpldapadmin but the users who
are already members are not displayed. An error is however correctly
displayed if you try to add a user who is already a member.
5. You can still manipulate the posixGroup as if it were a security
group, set acl's and permissions etc from the security tab of a file or
folder.
6. You can use a big hammer to add attributes that you should not be
able to add. e.g. you can add gidNumber without the objectClass (which
supplies gidNumber) being present using ldapmodify or ldbmodify.
7. posixAccount and its associated attributes work exactly as advertised
in the schema.
Conclusion:
This is simply an inconvenience. Everything works as expected except
being able to view the members that are in a group either in ADCU or
phpldapadmin _after_ you have added objectClass: posixGroup to it.
Why does adding the posixGroup Class knock out the ability to be able to
view group membership? Is this an error in the posixGroup schema? Is it
an aim that s4 be an _exact_ replacement for m$ AD?
Is this the schema that is used?
We use the exact schema Microsoft uses, provided to us by Microsoft as
part of the WSPP documentation.
from: MS-AD_Schema_2K8_R2_Classes, under
/usr/local/samba/share/setup/ad-schema
cn: PosixAccount
ldapDisplayName: posixAccount
...
There are full details of what we have tried with screenshots in the
latter part of this bugzilla:
https://bugzilla.samba.org/show_bug.cgi?id=8635
Please let us know if there is anything we can test.
Cheers,
Steve
(Could someone fwd to samba-tecnical?)
Why can't you raise this on samba-technical yourself?
If our behaviour differs from Microsoft's behaviour, then please raise
this as a bug. I haven't seen any reference to a difference in
behaviour that we could address.
Finally,
I know our idmapping situation in Samba4 sucks. It really, really
sucks. The reason it hasn't been addressed properly is two things: id
mapping is hard, and doing it right is difficult. Honouring uidNumber
and gidNumber attributes set in the directory seems reasonable, but we
cannot sensibly automatically assign those values, so what should we do
between creation of the user and the administrator choosing a uidNumber?
We'd probably suggest that Domain Admins don't have a uid or gid. What
they administer is irrelevant on Linux anyway so there's no need for
them to log onto it. I'm talking about giving domain users a uid and
gid, the gid being that of a Security group which has the posixGroup
object class added. In tests here, those users can then log onto both
Linux and windows and have both Security group properties for windows
and Linux group properties on Linux honoured perfectly. posix acl's seem
to play quite nice with windows acls too. The only one we can't mimic
exactly at file permission level is the windows 'modify'.
Using idmap_rid also seems quite reasonable, but to really be like AD we
should honour the trusted domain posixOffset parameter in doing that,
but we don't yet auto-allocate that posixOffset (handled on the RID
master).
There is also the issue that for proper ACL compatibility, uidNumber and
gidNumber actually causes problems - groups (domain administrators in
particular) need to own files - but if they only have a gidNumber, how
would we do that?
We've found that what you do with acls on windows (like not being able
to access the control panel) don't have any relevance in Linux. At file
ownership level posix to windows agreement is very good. We are setting
primaryGroupID for our Linux users and there is a m$ technet somewhere
where they suggest that unix gid could be mapped to primaryGroupID. ADUC
has a note about that when changing the group id. One thing we have
successfully setup on s4 is a group rw share. ACL's work identically for
our posixified group members. File permissions and ownership are
identical on both Lin and win sides in the share.
Andrew Bartlett
What is working well for us in tests is giving Domain Users a uid, gid,
setting their primaryGroupID to that of a posix-ified security group and
storing these attributes in their entry in sam.ldb. The only problem I
have with this is that adding the posixGroup objectClass to a security
group removes the ability to be able to list its members in ADUC and it
is really unfortunate that I can't test this against a windows server.
Because I don't have one. This is merely an inconvenience as the
posix-ified security group behaves exactly as if it were a normal domain
group. If we want point and click we can use phpldapadmin.
So, uid gid mapping and the interoperability of domain and posix groups
like this is really simple. What we fear may happen is that when an
official s4 mapping method comes along, it will make changes to either
the schema or sam.ldb which will disallow our storing our attributes in
the directory.
Are we wasting time proceding with this or does it make at least a
little sense? Our aim is simply to have a single sign on linux/windows.
As s4 does not provide an official mechanism for this at the moment we
invented this.
Thanks for your time,
Steve
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
