[Samba] [samba] How to configure Winbind to use uidNumber and gidNumber

mathias dufresne

unread,

Nov 10, 2015, 4:00:03 AM11/10/15

to

Hi all,

How can we configure winbind to retrieve uidNumber and gidNumber declared
in AD?

Thanks and regards,

mathias
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

L.P.H. van Belle

unread,

Nov 10, 2015, 4:10:03 AM11/10/15

to

Really.... here are your pointers..

First choose, since your not telling.. ADDC or Member server?

ADDC > https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller

Member > https://wiki.samba.org/index.php/Setup_Samba_as_an_AD_Domain_Member

ID Mapping => https://wiki.samba.org/index.php/Identity_Mapping_(idmap)

And when all configured, assigned if needed uid/gids..

Type :

getent passwd username ( DONT TEST WITH ADMINISTRATOR )
getent group "groupname" ( groups with spaces use the ")

Greetz,

Louis

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens mathias dufresne
> Verzonden: dinsdag 10 november 2015 9:49
> Aan: samba
> Onderwerp: [Samba] [samba] How to configure Winbind to use uidNumber and
> gidNumber

mathias dufresne

unread,

Nov 10, 2015, 8:50:03 AM11/10/15

to

Thank you for this quick answer Louis.

On DC:

On DC I had to add one line to have winbind retrieving uidNumber AD field
rather than having Winbind chosing some random UID for my users.
This line is:

idmap_ldb:use rfc2307 = yes

as explained in https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD

That's a start.

Unfortunately winbind is still giving my users GID number set to 100, which
is "Domain Users" group, when my users have gidNumber attribute set.

Same for shell, in AD loginShell is defined to /bin/bash for all my UNIX
users and winbind gives /bin/false on DC. Perhaps that's what it expected
by that tool but I still found that behaviour very confusing.
Please note I know there is a "template shell" option in smb.conf.
Unfortunately this option is, I think, to set all shell equal to that
template, for all users. That's not what we need. If some user in AD wants
to use CSH, this user must have a shell set to /bin/csh (or wherever it is
installed), if some user has to be set to /bin/false, it must be. And for
most of our users they would receive /bin/bash because it is what we
configure in loginShell by default.

Same for home directories. In AD I set unixHomeDirectory (I also tried with
homeDirectory field) to /home/<username> and in getent passwd <username> I
get home set to /home/<SAMBA.DOMAIN>/<username>

Anyway getent passwd <username> on DC is now working with users having UID
set to content of uidNumber field.
None of these users can connect on DC (even if uidNumber = 0) and I expect
this behaviour is because they have a shell set to /bin/false.

On member:

my smb.conf (from testparm)
---------------------------------------------------------------------
[global]
workgroup = SAMBA.DOMAIN
realm = SAMBA.DOMAIN.TLD
server string = Samba Server Version %v
security = ADS
log file = /var/log/samba/log.%m
max log size = 2048
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nss info = rfc2307
winbind normalize names = Yes
idmap config SAMBA.DOMAIN:range = 10000-2000000000
idmap config SAMBA.DOMAIN:schema_mode = rfc2307
idmap config SAMBA.DOMAIN:backend = ad
idmap config *:range = 2000-9999
idmap config * : backend = ad
cups options = raw

[homes]
comment = Home Directories
read only = No
browseable = No

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
print ok = Yes
browseable = No
---------------------------------------------------------------------

nsswitch.conf:
passwd: files winbind
shadow: files winbind
group: files winbind

and pam.d files are both configured:
---------------------------------------------------------------------
grep winb /etc/pam.d/*
/etc/pam.d/fingerprint-auth:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/fingerprint-auth:session optional pam_winbind.so
/etc/pam.d/fingerprint-auth-ac:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/fingerprint-auth-ac:session optional pam_winbind.so
/etc/pam.d/password-auth:auth sufficient pam_winbind.so
use_first_pass
/etc/pam.d/password-auth:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/password-auth:password sufficient pam_winbind.so
use_authtok
/etc/pam.d/password-auth:session optional pam_winbind.so
/etc/pam.d/password-auth-ac:auth sufficient pam_winbind.so
use_first_pass
/etc/pam.d/password-auth-ac:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/password-auth-ac:password sufficient pam_winbind.so
use_authtok
/etc/pam.d/password-auth-ac:session optional pam_winbind.so
/etc/pam.d/smartcard-auth:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/smartcard-auth:session optional pam_winbind.so
/etc/pam.d/smartcard-auth-ac:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/smartcard-auth-ac:session optional pam_winbind.so
/etc/pam.d/system-auth:auth sufficient pam_winbind.so
use_first_pass
/etc/pam.d/system-auth:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/system-auth:password sufficient pam_winbind.so use_authtok
/etc/pam.d/system-auth:session optional pam_winbind.so
/etc/pam.d/system-auth-ac:auth sufficient pam_winbind.so
use_first_pass
/etc/pam.d/system-auth-ac:account [default=bad success=ok
user_unknown=ignore] pam_winbind.so
/etc/pam.d/system-auth-ac:password sufficient pam_winbind.so
use_authtok
/etc/pam.d/system-auth-ac:session optional pam_winbind.so
---------------------------------------------------------------------

Here are the logs generated during getent passwd commands, extracted from
log.winbindd on member server (with log level = 3 winbind:9)

getent passwd <username>
---------------------------------------------------------------------
[2015/11/10 13:16:37.550045, 6]
../source3/winbindd/winbindd.c:871(new_connection)
accepted socket 22
[2015/11/10 13:16:37.550141, 3]
../source3/winbindd/winbindd_misc.c:395(winbindd_interface_version)
[ 2906]: request interface version
[2015/11/10 13:16:37.550294, 3]
../source3/winbindd/winbindd_misc.c:428(winbindd_priv_pipe_dir)
[ 2906]: request location of privileged pipe
[2015/11/10 13:16:37.550440, 6]
../source3/winbindd/winbindd.c:871(new_connection)
accepted socket 28
[2015/11/10 13:16:37.550478, 6]
../source3/winbindd/winbindd.c:919(winbind_client_request_read)
closing socket 22, client exited
[2015/11/10 13:16:37.550506, 3]
../source3/winbindd/winbindd_getpwnam.c:56(winbindd_getpwnam_send)
getpwnam stephane.morin
[2015/11/10 13:16:37.550633, 7]
../source3/winbindd/winbindd_ads.c:61(ads_cached_connection_reuse)
Current tickets expire in 34856 seconds (at 1447192653, time is now
1447157797)
[2015/11/10 13:16:41.259064, 5]
../source3/winbindd/winbindd_cache.c:1272(resolve_alias_to_username)
resolve_alias_to_username: backend query returned NT_STATUS_OK
[2015/11/10 13:16:41.281997, 5]
../source3/winbindd/winbindd_getpwnam.c:137(winbindd_getpwnam_recv)
Could not convert sid S-1-5-21-569364669-4183652282-291509484-43151:
NT_STATUS_NONE_MAPPED
[2015/11/10 13:16:41.282169, 6]
../source3/winbindd/winbindd.c:919(winbind_client_request_read)
closing socket 28, client exited

getent passwd SAMBA.DOMAIN\\<username>
---------------------------------------------------------------------
[2015/11/10 13:16:50.109816, 6]
../source3/winbindd/winbindd.c:871(new_connection)
accepted socket 22
[2015/11/10 13:16:50.109924, 3]
../source3/winbindd/winbindd_misc.c:395(winbindd_interface_version)
[ 2907]: request interface version
[2015/11/10 13:16:50.109977, 3]
../source3/winbindd/winbindd_misc.c:428(winbindd_priv_pipe_dir)
[ 2907]: request location of privileged pipe
[2015/11/10 13:16:50.110069, 6]
../source3/winbindd/winbindd.c:871(new_connection)
accepted socket 28
[2015/11/10 13:16:50.110130, 6]
../source3/winbindd/winbindd.c:919(winbind_client_request_read)
closing socket 22, client exited
[2015/11/10 13:16:50.110162, 3]
../source3/winbindd/winbindd_getpwnam.c:56(winbindd_getpwnam_send)
getpwnam ad.dgfip\stephane.morin
[2015/11/10 13:16:50.110403, 5]
../source3/winbindd/winbindd_getpwnam.c:137(winbindd_getpwnam_recv)
Could not convert sid S-1-5-21-569364669-4183652282-291509484-43151:
NT_STATUS_NONE_MAPPED
[2015/11/10 13:16:50.110552, 6]
../source3/winbindd/winbindd.c:919(winbind_client_request_read)
closing socket 28, client exited
---------------------------------------------------------------------

And wbinfo -i <username> does not work:
wbinfo -i administrator
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user administrator
Same behaviour for others users.

---------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------

Now wbinfo:
-------------------------------------------------
wbinfo -u
-------------------------------------------------
On DCs:
wbinfo -u on DCs does not show anything. It just gives up after few seconds
(around 10s on both DCs tested).

On member:
wbinfo -u | wc -l
49504

when
ldbsearch -H $sam objectcategory=person | tail -3
# returned 49507 records
# 49504 entries
# 3 referrals

So wbinfo -u returns all users on this member server.

-------------------------------------------------
wbinfo -i <username>
-------------------------------------------------
On DCs:
wbinfo -i administrator
SAMBA.DOMAIN\administrator:*:0:100::/home/SAMBA.DOMAIN/administrator:/bin/false
wbinfo -i mathias
SAMBA.DOMAIN\mathias:*:0:100:mathias
dufresne:/home/SAMBA.DOMAIN/mathias:/bin/false
wbinfo -i <username>
SAMBA.DOMAIN\<username>:*:1013569430:100:<username>:/home/SAMBA.DOMAIN/<username>:/bin/false

On member:
wbinfo -i administrator
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user administrator
wbinfo -i mathias
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user mathias
wbinfo -i <username>
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user <username>

On member I was using Samba packages from Centos 7 (it's a Centos 7) with
version 4.1.12-24.el7_1.
I switched to version 4.3.1 (the one I'm using for DCs) and result are the
same.

I'm facing a real lack of knowledge and I didn't yet find what to read to
fill these lacks.

Cheers,

mathias

Rowland Penny

unread,

Nov 10, 2015, 9:00:03 AM11/10/15

to

On 10/11/15 13:42, mathias dufresne wrote:
> Thank you for this quick answer Louis.
>
> On DC:
>
> On DC I had to add one line to have winbind retrieving uidNumber AD field
> rather than having Winbind chosing some random UID for my users.
> This line is:
>
> idmap_ldb:use rfc2307 = yes
>
> as explained in https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD
>
> That's a start.
>
> Unfortunately winbind is still giving my users GID number set to 100, which
> is "Domain Users" group, when my users have gidNumber attribute set.

unfortunately the contents of the 'gidNumber' attribute is not used for
the users GID, you need to give 'Domain Users' a gidNumber and this is
what will be used.

>
> Same for shell, in AD loginShell is defined to /bin/bash for all my UNIX
> users and winbind gives /bin/false on DC. Perhaps that's what it expected
> by that tool but I still found that behaviour very confusing.
> Please note I know there is a "template shell" option in smb.conf.
> Unfortunately this option is, I think, to set all shell equal to that
> template, for all users. That's not what we need. If some user in AD wants
> to use CSH, this user must have a shell set to /bin/csh (or wherever it is
> installed), if some user has to be set to /bin/false, it must be. And for
> most of our users they would receive /bin/bash because it is what we
> configure in loginShell by default.

You can only use the 'template' lines on the DC, if you need to have
different home dirs or shells, use a member server.

>
> Same for home directories. In AD I set unixHomeDirectory (I also tried with
> homeDirectory field) to /home/<username> and in getent passwd <username> I
> get home set to /home/<SAMBA.DOMAIN>/<username>
>
> Anyway getent passwd <username> on DC is now working with users having UID
> set to content of uidNumber field.
> None of these users can connect on DC (even if uidNumber = 0) and I expect
> this behaviour is because they have a shell set to /bin/false.

Correct, if you want to login to the DC, use 'template shell = /bin/bash'

Rowland

Michael Adam

unread,

Nov 11, 2015, 2:00:04 AM11/11/15

to

On 2015-11-10 at 13:57 +0000, Rowland Penny wrote:
> On 10/11/15 13:42, mathias dufresne wrote:
> >Thank you for this quick answer Louis.
> >
> >On DC:
> >
> >On DC I had to add one line to have winbind retrieving uidNumber AD field
> >rather than having Winbind chosing some random UID for my users.
> >This line is:
> >
> >idmap_ldb:use rfc2307 = yes
> >
> >as explained in https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD
> >
> >That's a start.
> >
> >Unfortunately winbind is still giving my users GID number set to 100, which
> >is "Domain Users" group, when my users have gidNumber attribute set.
>
> unfortunately the contents of the 'gidNumber' attribute is not used for the
> users GID, you need to give 'Domain Users' a gidNumber and this is what will
> be used.

That is not unfortunate, but the right thing to do (imho),
because the domain users group (or whatever the primary AD
level group is for the user) is what will appear in the access
token when the user accesses a file server.

We can think about making the use of the gidNumber attribute
a configurable option (at least for the start in the domain
member case with idmap_ad). But again, the right thing to do
is use the SID-level primary group for primary gid of the unix
user.

> >Same for shell, in AD loginShell is defined to /bin/bash for all my UNIX
> >users and winbind gives /bin/false on DC. Perhaps that's what it expected
> >by that tool but I still found that behaviour very confusing.
> >Please note I know there is a "template shell" option in smb.conf.
> >Unfortunately this option is, I think, to set all shell equal to that
> >template, for all users. That's not what we need. If some user in AD wants
> >to use CSH, this user must have a shell set to /bin/csh (or wherever it is
> >installed), if some user has to be set to /bin/false, it must be. And for
> >most of our users they would receive /bin/bash because it is what we
> >configure in loginShell by default.
>
> You can only use the 'template' lines on the DC, if you need to have
> different home dirs or shells, use a member server.

As discussed elsewhere, we should add the feature to use the AD
attributes (configurably). Someone has to find the time to
implement the changes.

Cheers - Michael

signature.asc

Rowland Penny

unread,

Nov 11, 2015, 3:20:03 AM11/11/15

to

On 11/11/15 06:52, Michael Adam wrote:
> On 2015-11-10 at 13:57 +0000, Rowland Penny wrote:
>> On 10/11/15 13:42, mathias dufresne wrote:
>>> Thank you for this quick answer Louis.
>>>
>>> On DC:
>>>
>>> On DC I had to add one line to have winbind retrieving uidNumber AD field
>>> rather than having Winbind chosing some random UID for my users.
>>> This line is:
>>>
>>> idmap_ldb:use rfc2307 = yes
>>>
>>> as explained in https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD
>>>
>>> That's a start.
>>>
>>> Unfortunately winbind is still giving my users GID number set to 100, which
>>> is "Domain Users" group, when my users have gidNumber attribute set.
>> unfortunately the contents of the 'gidNumber' attribute is not used for the
>> users GID, you need to give 'Domain Users' a gidNumber and this is what will
>> be used.
> That is not unfortunate, but the right thing to do (imho),
> because the domain users group (or whatever the primary AD
> level group is for the user) is what will appear in the access
> token when the user accesses a file server.

Well, it is unfortunate if you expected it to be used, but yes it is the
right thing to do.

>
> We can think about making the use of the gidNumber attribute
> a configurable option (at least for the start in the domain
> member case with idmap_ad). But again, the right thing to do
> is use the SID-level primary group for primary gid of the unix
> user.

You don't actually need the gidNumber, every users primary group is
'Domain Users', you can change this, but it is slightly complicated and
it breaks things on windows.

>
>
>>> Same for shell, in AD loginShell is defined to /bin/bash for all my UNIX
>>> users and winbind gives /bin/false on DC. Perhaps that's what it expected
>>> by that tool but I still found that behaviour very confusing.
>>> Please note I know there is a "template shell" option in smb.conf.
>>> Unfortunately this option is, I think, to set all shell equal to that
>>> template, for all users. That's not what we need. If some user in AD wants
>>> to use CSH, this user must have a shell set to /bin/csh (or wherever it is
>>> installed), if some user has to be set to /bin/false, it must be. And for
>>> most of our users they would receive /bin/bash because it is what we
>>> configure in loginShell by default.
>> You can only use the 'template' lines on the DC, if you need to have
>> different home dirs or shells, use a member server.
> As discussed elsewhere, we should add the feature to use the AD
> attributes (configurably). Someone has to find the time to
> implement the changes.

I think this really needs to be given a bit more priority than it has in
the past, get this working and you get a good replacement for the now
defunct SBS server.

Rowland

mathias dufresne

unread,

Nov 12, 2015, 8:10:04 AM11/12/15

to

That's for that same reason I don't agree and think it is not fair to not
give Samba admins the choice.
If all my 120000 users have primary group id set to 100, as you said all
newly created object onUNIX shares will be owned by group n°100 and so
accessible to the whole company.
I'm too thick to see where is the security improvement in that.

>
> We can think about making the use of the gidNumber attribute
> a configurable option (at least for the start in the domain
> member case with idmap_ad). But again, the right thing to do
> is use the SID-level primary group for primary gid of the unix
> user.
>

> No. In IT there are at least two worlds: UNIX world and Windows world.
Let's imagine 2s that a company wants to manage these worlds a little
differently. If we are forced to use Windows primary group as UNIX primary
group it seems to me difficult to manage these worlds differently.

And I don't feel like I'm asking something really new or inventing
anything: Microsoft designed its own AD with something to store Windows
users primary group then some guys thought (fought certainly) together to
produce rfc2307 which, strangely, comes with its own primary group
attribute for UNIX world.
Refusing us the possibility to use that gidNumber attribute is, in my own
opinion, equal to say rfc2307 contains bad ideas, at least regarding this
attribute gidNumber.

>
> > >Same for shell, in AD loginShell is defined to /bin/bash for all my UNIX
> > >users and winbind gives /bin/false on DC. Perhaps that's what it
> expected
> > >by that tool but I still found that behaviour very confusing.
> > >Please note I know there is a "template shell" option in smb.conf.
> > >Unfortunately this option is, I think, to set all shell equal to that
> > >template, for all users. That's not what we need. If some user in AD
> wants
> > >to use CSH, this user must have a shell set to /bin/csh (or wherever it
> is
> > >installed), if some user has to be set to /bin/false, it must be. And
> for
> > >most of our users they would receive /bin/bash because it is what we
> > >configure in loginShell by default.
> >
> > You can only use the 'template' lines on the DC, if you need to have
> > different home dirs or shells, use a member server.
>
> As discussed elsewhere, we should add the feature to use the AD
> attributes (configurably). Someone has to find the time to
> implement the changes.
>

That's exactly what I'm asking for months now and I deeply regret to not be
better in development, I would have tried to help more (I tried but these
tries just show me how much deep are my lacks of knowledge). And yes I'm
asking for options, to give us choice. I don't say the choices made until
now by Samba are wrong, I ask for options, for we can make different
choices.

Best regards,

mathias

mathias dufresne

unread,

Nov 12, 2015, 8:30:03 AM11/12/15

to

No more comment. For today :p

>
>
>
>> We can think about making the use of the gidNumber attribute
>> a configurable option (at least for the start in the domain
>> member case with idmap_ad). But again, the right thing to do
>> is use the SID-level primary group for primary gid of the unix
>> user.
>>
>
> You don't actually need the gidNumber, every users primary group is
> 'Domain Users', you can change this, but it is slightly complicated and it
> breaks things on windows.

Seriously Rowland...

First it is not complicated, changing one attribute value for one user or
for all users in AD DB is not something complicated. A bit of LDIF, a bit
of ldbmodify, nothing complex.
But I agree changing pirmaryGroupID value would be dangerous. Dangerous
because of my lack of knowledge about Windows world.
To avoid side effect I would change that value and add a memberOf attribute
to my users for they are still in "Domain Users". Doing that I could use
Winbind to retrieve my AD users on UNIX systems, they would have something
else than 100 as GID and they would be in "Domain Users". Until some users
is not well created by some dude not paid enough to read carefully the doc
or too tired to pay attention. Then to understand what is missing for this
newly-created-user would be fun...

I expect the fact in RFC2307 there is a dedicated attribute to host UNIX
Primary Group ID (namely gidNumber) is to avoid all (and most certainly
more) issues described earlier.

Rowland Penny

unread,

Nov 12, 2015, 8:40:03 AM11/12/15

to

On 12/11/15 13:05, mathias dufresne wrote:
>
>
>
> That's for that same reason I don't agree and think it is not fair to not
> give Samba admins the choice.
> If all my 120000 users have primary group id set to 100, as you said all
> newly created object onUNIX shares will be owned by group n°100 and so
> accessible to the whole company.

This is the way windows works, you need to use windows ACLs to set just
who has access etc.

> I'm too thick to see where is the security improvement in that.

It works for windows.

>
>
> Let's imagine 2s that a company wants to manage these worlds a little
> differently. If we are forced to use Windows primary group as UNIX primary
> group it seems to me difficult to manage these worlds differently.

If you are use a version of a windows product, you have to use it like a
windows product. Windows ACLs give you broader scope to allow access. On
Unix you have ugo, owner:group:others i.e. one owner:one group: the
entire Unix world. On Windows it is: possibly allow every windows user:
possibly every windows group, you can also deny access and you can
inherit permissions.

>
> And I don't feel like I'm asking something really new or inventing
> anything: Microsoft designed its own AD with something to store Windows
> users primary group then some guys thought (fought certainly) together to
> produce rfc2307 which, strangely, comes with its own primary group
> attribute for UNIX world.

RFC2307 was designed for ldap and then taken up by windows for SFU.

> Refusing us the possibility to use that gidNumber attribute is, in my own
> opinion, equal to say rfc2307 contains bad ideas, at least regarding this
> attribute gidNumber.
>

No, it is just an artifact that you do not need, all you need to do is
create a group in AD, give that group a gidNumber, add a user to the
group and that user will have that group as one of its Unix groups.

Rowland

> That's exactly what I'm asking for months now and I deeply regret to not be
> better in development, I would have tried to help more (I tried but these
> tries just show me how much deep are my lacks of knowledge). And yes I'm
> asking for options, to give us choice. I don't say the choices made until
> now by Samba are wrong, I ask for options, for we can make different
> choices.
>
> Best regards,
>
> mathias
>
>

Rowland Penny

unread,

Nov 12, 2015, 8:50:04 AM11/12/15

to

On 12/11/15 13:22, mathias dufresne wrote:
>
>
> 2015-11-11 9:11 GMT+01:00 Rowland Penny <rowlandpe...@gmail.com

> <mailto:rowlandpe...@gmail.com>>:

Go on, try it, change a users primary group id by just changing their
'primaryGroupID', you will find it Doesn't work, it is more involved
than that.

> But I agree changing pirmaryGroupID value would be dangerous.
> Dangerous because of my lack of knowledge about Windows world.

If you have windows users and change a users primary group id, it could
break something because windows expects every user to be a member of
Domain Users.

> To avoid side effect I would change that value and add a memberOf
> attribute to my users for they are still in "Domain Users". Doing that
> I could use Winbind to retrieve my AD users on UNIX systems, they
> would have something else than 100 as GID and they would be in "Domain
> Users". Until some users is not well created by some dude not paid
> enough to read carefully the doc or too tired to pay attention. Then
> to understand what is missing for this newly-created-user would be fun...

You could do this, but it could get terribly messy.

>
> I expect the fact in RFC2307 there is a dedicated attribute to host
> UNIX Primary Group ID (namely gidNumber) is to avoid all (and most
> certainly more) issues described earlier.

Yes, but you do not need the gidNumber.

mathias dufresne

unread,

Nov 12, 2015, 9:00:04 AM11/12/15

to

I won't, there are tools to do what I want in nices ways (nslcd, sssd at
least).
Winbind is really close to give us that possibility too and I'm almost sure
this tool will also be improved one day to give us usage of all rfc2307
attributes.

>
> But I agree changing pirmaryGroupID value would be dangerous. Dangerous
>> because of my lack of knowledge about Windows world.
>>
>
> If you have windows users and change a users primary group id, it could
> break something because windows expects every user to be a member of Domain
> Users.
>
> To avoid side effect I would change that value and add a memberOf
>> attribute to my users for they are still in "Domain Users". Doing that I
>> could use Winbind to retrieve my AD users on UNIX systems, they would have
>> something else than 100 as GID and they would be in "Domain Users". Until
>> some users is not well created by some dude not paid enough to read
>> carefully the doc or too tired to pay attention. Then to understand what is
>> missing for this newly-created-user would be fun...
>>
>
> You could do this, but it could get terribly messy.

In fact I won't.

>
>
>
>> I expect the fact in RFC2307 there is a dedicated attribute to host UNIX
>> Primary Group ID (namely gidNumber) is to avoid all (and most certainly
>> more) issues described earlier.
>>
>
> Yes, but you do not need the gidNumber.

In fact, I do.

mathias dufresne

unread,

Nov 12, 2015, 9:00:04 AM11/12/15

to

Missed! Not by much, but still :)

You speak to me as if you were teaching to a really-dumb-student beginning
Linux system administration. Do you think I'm dumb or do you thin I begin
playing sysadmin?

One point you forgot here: the process you described is to give users
secondary groups when we are speaking about primary group.

You also forget in that process to specify I would need to force all my
users to use "sg" command at login time for they switch one of their
secondary group to the primary one. Because sometimes primary group in UNIX
world is important.

Rowland Penny

unread,

Nov 12, 2015, 9:10:04 AM11/12/15

to

No you don't, you just think you do, probably because you are thinking
like a Unix sysadmin, AD is a windows thing, so you need to think like a
windows sysadmin when it comes to permissions.

Rowland Penny

unread,

Nov 12, 2015, 9:20:04 AM11/12/15

to

No, I think you are a Unix sysadmin lost in a windows AD world :-)

>
> One point you forgot here: the process you described is to give users
> secondary groups when we are speaking about primary group.

Yes, but in an AD world, there isn't really that much difference between
a primary and a secondary group.

>
> You also forget in that process to specify I would need to force all my
> users to use "sg" command at login time for they switch one of their
> secondary group to the primary one. Because sometimes primary group in UNIX
> world is important.
>

Yes, in a UNIX world, you need to think in a windows way instead.

I give in, you go your way and I will go mine, there is very little
chance we are going to agree on this.

Rowland

mathias dufresne

unread,

Nov 12, 2015, 11:10:03 AM11/12/15

to

I'm not.
I'm speaking from the beginning about gidNumber usage.
As AD comes with all we need to manage Windows users, as gidNumber is part
of RFC2307 which comes to manage UNIX users, I thought you would have been
able from the beginning to understand I want to use AD features to host
also UNIX users (in fact to have users in AD which are Windows and UNIX
users).

Perhaps you are a bit lost trying to be everywhere answering to every mails
: )

>
>
>
>> One point you forgot here: the process you described is to give users
>> secondary groups when we are speaking about primary group.
>>
>
> Yes, but in an AD world, there isn't really that much difference between a
> primary and a secondary group.

AD is nothing if it is not used. I'm speaking about usage of its content.
And usage of its content happen on different contexts. Could be users from
some Web App, could user for Windows systems, UNIX systems and so much more
I don't even heard about.

Anyway, in UNIX primary group is important. Who's lost?

>
>
>
>> You also forget in that process to specify I would need to force all my
>> users to use "sg" command at login time for they switch one of their
>> secondary group to the primary one. Because sometimes primary group in
>> UNIX
>> world is important.
>>
>>
> Yes, in a UNIX world, you need to think in a windows way instead.

False. Why do you force me to say that to you every two days?
In UNIX world I think UNIX. In UNIX world when I retrieve AD users I manage
to create my UNIX users as my UNIX need to. And you know, this idea seems
to me not so wrong as some guys have already developed all the tools I need
to that.
But I know you now Rowland. That's not your way of mind so me and all these
guys are stupid, according to what you show.

> I give in, you go your way and I will go mine, there is very little chance
> we are going to agree on this.

Yes please, speak to someone else :)

mathias dufresne

unread,

Nov 12, 2015, 11:30:04 AM11/12/15

to

I fully understand on Linux system used to serve files to Windows clients
these servers should create users using the Windows way, for ACLs
compatibility and so on.
To achieve that, quiet simple: winbind to retrieve users from AD.

My point about gidNumber is when using AD as a database of users on UNIX
system, for UNIX stuffs.