Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[Samba] Corrupted idmap...

969 views
Skip to first unread message

Ryan Ashley via samba

unread,
Jan 11, 2017, 10:50:03 AM1/11/17
to
I started getting NT_STATUS_INVALID at a client location recently and
now everything has stopped working. Upon a day of searching and testing,
I realized that my idmap.ldb is likely corrupt. How can I recover from
this, shy of creating a new domain from scratch? The NAS devices no
longer authenticate users so files are inaccessible, computers cannot
access the sysvol, and sysvolreset/sysvolcheck both fail. Thanks in
advance for any help in this matter.

--
Lead IT/IS Specialist
Reach Technology FP, Inc

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

Rowland Penny via samba

unread,
Jan 11, 2017, 11:10:03 AM1/11/17
to
On Wed, 11 Jan 2017 09:23:13 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

> I started getting NT_STATUS_INVALID at a client location recently and
> now everything has stopped working. Upon a day of searching and
> testing, I realized that my idmap.ldb is likely corrupt. How can I
> recover from this, shy of creating a new domain from scratch? The NAS
> devices no longer authenticate users so files are inaccessible,
> computers cannot access the sysvol, and sysvolreset/sysvolcheck both
> fail. Thanks in advance for any help in this matter.
>

What is actually wrong with your idmap.ldb ?

Rowland

lingpanda101 via samba

unread,
Jan 11, 2017, 11:10:03 AM1/11/17
to
On 1/11/2017 9:23 AM, Ryan Ashley via samba wrote:
> I started getting NT_STATUS_INVALID at a client location recently and
> now everything has stopped working. Upon a day of searching and testing,
> I realized that my idmap.ldb is likely corrupt. How can I recover from
> this, shy of creating a new domain from scratch? The NAS devices no
> longer authenticate users so files are inaccessible, computers cannot
> access the sysvol, and sysvolreset/sysvolcheck both fail. Thanks in
> advance for any help in this matter.
>

If you have a secondary DC that has a good idmap.ldb, transfer the FSMO
roles and remove the corrupt DC. Second option is to restore from
backups. Otherwise you can try and manually recover by posting your
error logs from Samba and your smb.conf.

--
- James

Ryan Ashley via samba

unread,
Jan 11, 2017, 12:20:04 PM1/11/17
to
Rowland, no domain user can authenticate on any system and running
sysvolreset followed by sysvolcheck results in a crash. If the sysvol
permissions are correct, sysvolcheck does not crash. If I attempt to
join a NAS or workstation to the domain I get NT_STATUS_INVALID_SID.
Researching these symptoms turns up a thread about a corrupt idmap.ldb
where a group SID and user SID may be the same or something like that.

They've been down for two days now. They do not have a backup DC. They
did, but it was truck by lightning (it got the battery backup and all)
and they chose not to replace it, against my recommendation. Either way,
no backup DC to recover with.

Finally, which logs would you like to see? My winbindd-idmap log has
nothing but segfaults logged. What log should I check? The only thing
which stood out was the smbd log, which I pasted part of below.

[2017/01/10 13:00:45.581992, 0]
../source4/auth/unix_token.c:79(security_token_to_unix_token)
Unable to convert first SID (S-1-5-7) in user token to a UID.
Conversion was returned as type 0, full token:
[2017/01/10 13:00:45.659202, 0]
../libcli/security/security_token.c:63(security_token_debug)
Security token SIDs (3):
SID[ 0]: S-1-5-7
SID[ 1]: S-1-1-0
SID[ 2]: S-1-5-2
Privileges (0x 0):
Rights (0x 0):
[2017/01/10 13:00:46.378251, 0]
../source4/auth/unix_token.c:79(security_token_to_unix_token)
Unable to convert first SID
(S-1-5-21-2812428577-3463248684-2415680475-1105) in user token to a UID.
Conversion was returned as type 0, full token:
[2017/01/10 13:00:46.425549, 0]
../libcli/security/security_token.c:63(security_token_debug)
Security token SIDs (7):
SID[ 0]: S-1-5-21-2812428577-3463248684-2415680475-1105
SID[ 1]: S-1-5-21-2812428577-3463248684-2415680475-515
SID[ 2]: S-1-1-0
SID[ 3]: S-1-5-2
SID[ 4]: S-1-5-11
SID[ 5]: S-1-5-32-554
SID[ 6]: S-1-5-32-545
Privileges (0x 800000):
Privilege[ 0]: SeChangeNotifyPrivilege
Rights (0x 400):
Right[ 0]: SeRemoteInteractiveLogonRight
[2017/01/10 13:00:47.052039, 0]
../source4/auth/unix_token.c:79(security_token_to_unix_token)
Unable to convert first SID
(S-1-5-21-2812428577-3463248684-2415680475-1105) in user token to a UID.
Conversion was returned as type 0, full token:
[2017/01/10 13:00:47.133721, 0]
../libcli/security/security_token.c:63(security_token_debug)
Security token SIDs (7):
SID[ 0]: S-1-5-21-2812428577-3463248684-2415680475-1105
SID[ 1]: S-1-5-21-2812428577-3463248684-2415680475-515
SID[ 2]: S-1-1-0
SID[ 3]: S-1-5-2
SID[ 4]: S-1-5-11
SID[ 5]: S-1-5-32-554
SID[ 6]: S-1-5-32-545
Privileges (0x 800000):
Privilege[ 0]: SeChangeNotifyPrivilege
Rights (0x 400):
Right[ 0]: SeRemoteInteractiveLogonRight
[2017/01/10 13:00:47.698611, 0]
../source4/auth/unix_token.c:79(security_token_to_unix_token)
Unable to convert first SID (S-1-5-7) in user token to a UID.
Conversion was returned as type 0, full token:
[2017/01/10 13:00:47.775770, 0]
../libcli/security/security_token.c:63(security_token_debug)
Security token SIDs (3):
SID[ 0]: S-1-5-7
SID[ 1]: S-1-1-0
SID[ 2]: S-1-5-2
Privileges (0x 0):
Rights (0x 0):
[2017/01/10 13:00:48.394629, 0]
../source4/auth/unix_token.c:79(security_token_to_unix_token)
Unable to convert first SID
(S-1-5-21-2812428577-3463248684-2415680475-1105) in user token to a UID.
Conversion was returned as type 0, full token:
[2017/01/10 13:00:48.409271, 0]
../libcli/security/security_token.c:63(security_token_debug)
Security token SIDs (7):
SID[ 0]: S-1-5-21-2812428577-3463248684-2415680475-1105
SID[ 1]: S-1-5-21-2812428577-3463248684-2415680475-515
SID[ 2]: S-1-1-0
SID[ 3]: S-1-5-2
SID[ 4]: S-1-5-11
SID[ 5]: S-1-5-32-554
SID[ 6]: S-1-5-32-545
Privileges (0x 800000):
Rights (0x 400):
root@dc01:~# samba -b
Samba version: 4.5.0
Build environment:
Build host: Linux dc01 3.2.0-4-amd64 #1 SMP Debian 3.2.81-2 x86_64
GNU/Linux
Paths:
BINDIR: /usr/bin
SBINDIR: /usr/sbin
CONFIGFILE: /etc/samba/smb.conf
NCALRPCDIR: /var/run/samba/ncalrpc
LOGFILEBASE: /var/log/samba
LMHOSTSFILE: /etc/samba/lmhosts
DATADIR: /usr/share
MODULESDIR: /usr/lib/samba
LOCKDIR: /var/lock/samba
STATEDIR: /var/lib/samba
CACHEDIR: /var/cache/samba
PIDDIR: /var/run/samba
PRIVATE_DIR: /var/lib/samba/private
CODEPAGEDIR: /usr/share/samba/codepages
SETUPDIR: /usr/share/samba/setup
WINBINDD_SOCKET_DIR: /var/run/samba/winbindd
WINBINDD_PRIVILEGED_SOCKET_DIR: /var/lib/samba/winbindd_privileged
NTP_SIGND_SOCKET_DIR: /var/lib/samba/ntp_signd
root@dc01:~#

That looks like my issue, but I am not sure.

Lead IT/IS Specialist
Reach Technology FP, Inc

On 01/11/2017 11:05 AM, lingpanda101 via samba wrote:
> On 1/11/2017 9:23 AM, Ryan Ashley via samba wrote:
>> I started getting NT_STATUS_INVALID at a client location recently and
>> now everything has stopped working. Upon a day of searching and testing,
>> I realized that my idmap.ldb is likely corrupt. How can I recover from
>> this, shy of creating a new domain from scratch? The NAS devices no
>> longer authenticate users so files are inaccessible, computers cannot
>> access the sysvol, and sysvolreset/sysvolcheck both fail. Thanks in
>> advance for any help in this matter.
>>
>
> If you have a secondary DC that has a good idmap.ldb, transfer the FSMO
> roles and remove the corrupt DC. Second option is to restore from
> backups. Otherwise you can try and manually recover by posting your
> error logs from Samba and your smb.conf.
>

--

Rowland Penny via samba

unread,
Jan 11, 2017, 12:40:03 PM1/11/17
to
On Wed, 11 Jan 2017 12:14:32 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

You could try examining idmap.ldb:

ldbedit -e nano -H /var/lib/samba/private/idmap.ldb

It should contain records like these:

dn: CN=S-1-5-21-1768301897-3342589593-1064908849-502
cn: S-1-5-21-1768301897-3342589593-1064908849-502
objectClass: sidMap
objectSid: S-1-5-21-1768301897-3342589593-1064908849-502
type: ID_TYPE_BOTH
xidNumber: 3000045
distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-502

dn: CN=S-1-5-21-1768301897-3342589593-1064908849-500
cn: S-1-5-21-1768301897-3342589593-1064908849-500
objectClass: sidMap
objectSid: S-1-5-21-1768301897-3342589593-1064908849-500
type: ID_TYPE_UID
xidNumber: 0
distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-500

dn: CN=S-1-5-21-1768301897-3342589593-1064908849-2101
cn: S-1-5-21-1768301897-3342589593-1064908849-2101
objectClass: sidMap
objectSid: S-1-5-21-1768301897-3342589593-1064908849-2101
type: ID_TYPE_BOTH
xidNumber: 3000046
distinguishedName: CN=S-1-5-21-1768301897-3342589593-1064908849-2101

Check for duplicate 'xidNumbers'
Also, as you say the other DC died (or is that fried ?), check the FSMO
roles and ensure there is no mention of the dead DC in sam.ldb (you may
have to use '--cross-ncs' & -show-binary' with ldbsearch or ldbedit)

Rowland

lingpanda101 via samba

unread,
Jan 11, 2017, 12:40:03 PM1/11/17
to
I'm reminded of this bug
https://bugzilla.samba.org/show_bug.cgi?id=12410 with regards to your
issue. You didn't post your smb.conf, so can't say for sure.

--
- James

Ryan Ashley via samba

unread,
Jan 12, 2017, 10:30:03 AM1/12/17
to
Rowland, the secondary DC died, this is the primary, and yes it was
fried. Smelled like somebody was cooking smores made of electrical wires
and circuit boards in that room!

Is there a way to have ldbedit output that data so I can grep xidNumber?
There is a lot in there and keeping up with all of those numbers is a pain.

Lead IT/IS Specialist
Reach Technology FP, Inc

Ryan Ashley via samba

unread,
Jan 12, 2017, 10:40:05 AM1/12/17
to
I forgot about ldbsearch. Here is a dump of xid numbers.

root@dc01:~# ldbsearch -H /var/lib/samba/private/idmap.ldb | grep xidNumber
xidNumber: 3000028
xidNumber: 3000013
xidNumber: 3000033
xidNumber: 3000003
xidNumber: 3000032
xidNumber: 3000023
xidNumber: 3000019
xidNumber: 3000010
xidNumber: 65534
xidNumber: 3000031
xidNumber: 3000022
xidNumber: 3000026
xidNumber: 3000017
xidNumber: 3000027
xidNumber: 3000016
xidNumber: 3000030
xidNumber: 3000021
xidNumber: 3000004
xidNumber: 100
xidNumber: 3000008
xidNumber: 3000011
xidNumber: 0
xidNumber: 3000009
xidNumber: 3000025
xidNumber: 3000000
xidNumber: 3000001
xidNumber: 3000002
xidNumber: 3000014
xidNumber: 3000029
xidNumber: 3000020
xidNumber: 3000005
xidNumber: 3000006
xidNumber: 3000007
xidNumber: 3000018
xidNumber: 3000012
xidNumber: 3000024
xidNumber: 3000015

Is an xid number supposed to go all the way down to 0?

Lead IT/IS Specialist
Reach Technology FP, Inc

On 01/11/2017 12:33 PM, Rowland Penny via samba wrote:

Rowland Penny via samba

unread,
Jan 12, 2017, 10:50:02 AM1/12/17
to
On Thu, 12 Jan 2017 10:23:01 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

> Rowland, the secondary DC died, this is the primary, and yes it was
> fried. Smelled like somebody was cooking smores made of electrical
> wires and circuit boards in that room!
>
> Is there a way to have ldbedit output that data so I can grep
> xidNumber? There is a lot in there and keeping up with all of those
> numbers is a pain.
>

Very easily (provided ldbedit shows all the data in idmap.ldb) ;-)

Use ldbsearch and dump it into a file:

ldbsearch -H /var/lib/samba/private/idmap.ldb > idmap.txt

Rowland Penny via samba

unread,
Jan 12, 2017, 11:00:03 AM1/12/17
to
Yes, '0' is administrator (and also root)
'100' is the users group and '65534' is the user 'nobody'

Only problem I can see, you do not have any duplicate xidNumbers, but
that doesn't mean you don't have any SIDs with more than one xidNumber

Ryan Ashley via samba

unread,
Jan 13, 2017, 12:50:03 PM1/13/17
to
OK, I noticed that also, but why does everything return
NT_STATUS_INVALID_SID? Even if I run "smbclient -L \\localhost -U
adminnamehere" on the DC itself, I get the error. At this point we are
looking at erasing every workstation, wiping the DC, and starting from
scratch. It has been a week and not even rolling back to 4.4 fixed it.
What should my next steps be? I attached the server configuration file
for reference. Note that it has run this way for a year without a hitch
and nothing has been changed since day 1.

# Global parameters
[global]
workgroup = TRUEVINE
realm = TRUEVINE.LAN
netbios name = DC01
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
drepl, winbindd, ntp_signd, kcc, dnsupdate
idmap_ldb:use rfc2307 = yes
idmap config *:backend = tdb
idmap config *:range = 2001-10000
idmap config TRUEVINE:backend = ad
idmap config TRUEVINE:schema_mode = rfc2307
idmap config TRUEVINE:range = 10001-20000
domain master = yes
local master = yes
preferred master = yes
os level = 255

[netlogon]
path = /var/lib/samba/sysvol/truevine.lan/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

Lead IT/IS Specialist
Reach Technology FP, Inc

Rowland Penny via samba

unread,
Jan 13, 2017, 1:10:03 PM1/13/17
to
Now I have seen your smb.conf, I think I can tell you why you are
getting 'NT_STATUS_INVALID_SID'

You have 'idmap config' lines, these do nothing on a DC, or rather they
did nothing until 4.5.0, now they cause errors, so I would remove them.
I would also remove the 'master' lines and the 'os' line.

When 4.6.0 comes out, it is my understanding that you will not have this
problem, Samba will flat out refuse to start if you have the idmap
lines in smb.conf ;-)

Ryan Ashley via samba

unread,
Jan 14, 2017, 11:30:03 AM1/14/17
to
Rowland, I commented out what you asked me to, no change.

# Global parameters
[global]
workgroup = TRUEVINE
realm = TRUEVINE.LAN
netbios name = DC01
server role = active directory domain controller
server services = s3fs, rpc, nbt, wrepl, ldap, cldap, kdc,
drepl, winbi$
# idmap_ldb:use rfc2307 = yes
# idmap config *:backend = tdb
# idmap config *:range = 2001-10000
# idmap config TRUEVINE:backend = ad
# idmap config TRUEVINE:schema_mode = rfc2307
# idmap config TRUEVINE:range = 10001-20000
# domain master = yes
# local master = yes
# preferred master = yes
# os level = 255

[netlogon]
path = /var/lib/samba/sysvol/truevine.lan/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

Results:
root@dc01:~# nano -w /etc/samba/smb.conf
root@dc01:~# service samba4 stop
[ ok ] Stopping Samba AD DC daemon: samba.
root@dc01:~# service samba4 start
[ ok ] Starting Samba AD DC daemon: samba.
root@dc01:~# smbclient -L \\localhost -U administrator
Enter administrator's password:
session setup failed: NT_STATUS_INVALID_SID
root@dc01:~#

Lead IT/IS Specialist
Reach Technology FP, Inc

Rowland Penny via samba

unread,
Jan 14, 2017, 11:50:03 AM1/14/17
to
On Sat, 14 Jan 2017 11:17:57 -0500
Put 'idmap_ldb:use rfc2307 = yes' back, you need it, the idmap lines I
was referring to, start with 'idmap config'

Run 'net cache flush'
Ensure the libnss_winbind links exist, the 'passwd' & 'group' lines
in /etc/nsswitch.conf contain 'winbind' and PAM is set up correctly.
It may also help if you restart the DC

Ryan Ashley via samba

unread,
Jan 17, 2017, 9:50:02 AM1/17/17
to
Rowland, that opened up a whole new can of worms. I did exactly as
instructed, but when I did the "net cache flush" I got spammed with
stuff like the following, and I mean SPAMMED. Thousands of lines, way
beyond my scrollback buffer.

tdb(/var/lock/samba/gencache_notrans.tdb): tdb_expand overflow detected
current map_size[4294967295] size[96]!
tdb(/var/lock/samba/gencache_notrans.tdb): tdb_expand overflow detected
current map_size[4294967295] size[96]!
tdb(/var/lock/samba/gencache_notrans.tdb): tdb_expand overflow detected
current map_size[4294967295] size[96]!
tdb(/var/lock/samba/gencache_notrans.tdb): tdb_expand overflow detected
current map_size[4294967295] size[96]!

Looks like a database has grown too large or something. Not sure as I
have no experience with TDB, only MySQL and MSSQL.

Lead IT/IS Specialist
Reach Technology FP, Inc

Ryan Ashley via samba

unread,
Jan 17, 2017, 10:10:04 AM1/17/17
to
Rowland, I was just reading over another thread on this list about the
inability to access group policy from client machines. The user did not
have the symlinks setup (I do) but one thing you mentioned was using the
NIS attributes to set UID/GID numbers for the domain. You said we should
not do this for certain users and groups, but there is no mention of
this in the guides to setting up an AD DC, so I have always done it. We
do this to make our Linux-based NAS devices work.

Furthermore, you recommended the user use the idmap lines to ensure
consistent UID/GID numbers across devices, yet you suggested I turn the
exact same lines off in my config. Why is this? I understand our
situations are different, but when should we set winbind to use the AD
backend and set UID/GID numbers? How do do this so Linux-base file
services can be accessed by users and come out the same?

To be specific, these are the commented lines in my config file. They
look like what you recommended to the user Richard to ensure consistent
UID and GID numbers.

# idmap config *:backend = tdb
# idmap config *:range = 2001-10000
# idmap config TRUEVINE:backend = ad
# idmap config TRUEVINE:schema_mode = rfc2307
# idmap config TRUEVINE:range = 10001-20000

Lead IT/IS Specialist
Reach Technology FP, Inc

Rowland Penny via samba

unread,
Jan 17, 2017, 11:10:04 AM1/17/17
to
On Tue, 17 Jan 2017 10:04:23 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

Firstly , 'gencache_notrans.tdb' is a cache file and is recreated when
Samba is restarted.

> Rowland, I was just reading over another thread on this list about the
> inability to access group policy from client machines. The user did
> not have the symlinks setup (I do) but one thing you mentioned was
> using the NIS attributes to set UID/GID numbers for the domain. You
> said we should not do this for certain users and groups, but there is
> no mention of this in the guides to setting up an AD DC, so I have
> always done it. We do this to make our Linux-based NAS devices work.

The only only windows group that needs a gidNumber attribute is Domain
Users and then only when you use the windbind 'ad' backend on a domain
member. the other windows groups don't need a gidNumber, in fact, as
Domain Admins needs to own directories in sysvol, you definitely
shouldn't give this group a gidNumber.
If you have to set up Samba this way because of your NAS, I would look
closely at your NAS ;-)

>
> Furthermore, you recommended the user use the idmap lines to ensure
> consistent UID/GID numbers across devices, yet you suggested I turn
> the exact same lines off in my config. Why is this? I understand our
> situations are different, but when should we set winbind to use the AD
> backend and set UID/GID numbers? How do do this so Linux-base file
> services can be accessed by users and come out the same?

You are mixing up idmap on a DC and a Unix domain member. On a DC,
idmapping is done in idmap.ldb, users & groups are allocated an
xidNumber in the '3000000' range, the number allocated is on the next
number available basis, apart from 'Administrator', 'Domain Users' and
'nobody' which get '0', '100' and '65534'.

On a Unix domain member, the two main ways of setting up idmapping is
with the winbind 'rid' and 'ad' backends. The 'rid' backends calculates
an ID from the windows RID, so you don't have to add anything to AD.
This means that whilst, by using the 'rid' backend, you will get the
same ID on every Unix domain member, it will still be different from
the ID on a DC (and the ID will probably be different on other DCs).

The only way to get the same ID everywhere is to use the 'ad' backend,
If you give a user a uidNumber and run 'net cache flush', this will be
used instead of the xidNumber without modifying smb.conf in any way.
On a Unix domain member it is different, you need to add something
like this:

idmap config *:backend = tdb
idmap config *:range = 2000-9999
## map ids from the domain the ranges may not overlap !
idmap config SAMDOM : backend = ad
idmap config SAMDOM : schema_mode = rfc2307
idmap config SAMDOM : range = 10000-999999

Now provided that the uidNumber attributes you have added are between
10000 and 999999 AND you have given Domain users a gidNumber in the
same range, getent will display info for your users.

Now somebody (and I know who) recommended adding those lines to the
smb.conf, but they do nothing on a DC, well they didn't until 4.5.0
came out and then they started causing errors, so bottom line, don't add
them to a Samba AD DC smb.conf

Ryan Ashley via samba

unread,
Jan 17, 2017, 1:20:02 PM1/17/17
to
The NAS in question is a QNAP. Great NAS, but it was recommended to use
NIS attributes to us so we used them. How can I correct all of this
since nothing can authenticate now? Start a new domain?

Lead IT/IS Specialist
Reach Technology FP, Inc

Ryan Ashley via samba

unread,
Jan 19, 2017, 8:40:04 AM1/19/17
to
OK, so since it appears our only recourse is to build a new domain from
scratch, how can we prevent this from happening again? We have several
Gentoo workstations, a bunch of Windows 7 workstations, and a few NAS
devices which run Linux of some flavor. How do we use NIS attributes
without killing our domain? The Samba guide even has instructions for
using ADUC to set the UID/GID for users and groups. You stated I should
only set a GID for "Domain Users", but what about other AD security
groups we create? This is a tad confusing since I thought NIS was needed
for our Linux systems and the NAS devices.

Lead IT/IS Specialist
Reach Technology FP, Inc

Rowland Penny via samba

unread,
Jan 19, 2017, 11:20:04 AM1/19/17
to
On Thu, 19 Jan 2017 08:32:02 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

> OK, so since it appears our only recourse is to build a new domain
> from scratch, how can we prevent this from happening again? We have
> several Gentoo workstations, a bunch of Windows 7 workstations, and a
> few NAS devices which run Linux of some flavor. How do we use NIS
> attributes without killing our domain? The Samba guide even has
> instructions for using ADUC to set the UID/GID for users and groups.
> You stated I should only set a GID for "Domain Users", but what about
> other AD security groups we create? This is a tad confusing since I
> thought NIS was needed for our Linux systems and the NAS devices.
>

OK, if you use the winbind 'ad' backend on Unix domain members, you
need to give the Windows group, that the users 'primaryGroupID'
attribute points to, a gidNumber. The 'primaryGroupID' usually points
to '513', which is the RID for Domain Users. If you do not give the
users primary group a gidnumber, the winbind 'ad' backend will ignore
all users, even if you have given every user a uidNumber.
This is the only group that you must give a gidNumber to if you're
using the winbind 'ad' backend on Unix domain members.

If you don't use the winbind 'ad' backend, then you do not need to add
anything to users and groups in AD.

If you do use the winbind 'ad' backend, then any of the Well Known SIDs
will be mapped via the '*' domain lines in smb.conf on the domain
members.

If you create any users or groups and you want them to be visible on
Unix domain members, you will need to give them a uidNumber or
gidNumber

Some people give Domain Admins a gidNumber, I cannot advise doing this.
This is because windows has the concept of a group owning directories
and files. On Unix, only a user can own directories and files and Domain
Admins needs to own Directories in sysvol.

I hope this helps, but as always, any questions, just ask.

Alex Crow via samba

unread,
Jan 21, 2017, 1:10:03 PM1/21/17
to
Yes, this does not make sense.

If I have member file servers, and I want to be in control of which
groups can access what, surely winbind needs to be able to get a GID
from AD?

It may be different in our case as we migrated from classic Samba, but
every non-builtin group we have has a GID assigned and it works
perfectly. Indeed, if I create a new group without assigning a Unix GID,
it is not even visible on the member file servers, so IMHO the advice
you've been given is not correct. Your non-builtin groups that you use
for file access controls must have a GID number if you're using rfc idmap.

I understand that idmap configuration is not usable on a DC.

Cheers

Alex
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
This email is not intended to, nor should it be taken to, constitute advice.
The information provided is correct to our knowledge & belief and must not
be used as a substitute for obtaining tax, regulatory, investment, legal or
any other appropriate advice.

"Transact" is operated by Integrated Financial Arrangements Ltd.
29 Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608 5300.
(Registered office: as above; Registered in England and Wales under
number: 3727592). Authorised and regulated by the Financial Conduct
Authority (entered on the Financial Services Register; no. 190856).

Rowland Penny via samba

unread,
Jan 21, 2017, 1:50:03 PM1/21/17
to
On Sat, 21 Jan 2017 18:05:52 +0000
Alex Crow via samba <sa...@lists.samba.org> wrote:

> Yes, this does not make sense.
>
> If I have member file servers, and I want to be in control of which
> groups can access what, surely winbind needs to be able to get a GID
> from AD?
>
> It may be different in our case as we migrated from classic Samba, but
> every non-builtin group we have has a GID assigned and it works
> perfectly. Indeed, if I create a new group without assigning a Unix
> GID, it is not even visible on the member file servers, so IMHO the
> advice you've been given is not correct. Your non-builtin groups that
> you use for file access controls must have a GID number if you're
> using rfc idmap.
>
> I understand that idmap configuration is not usable on a DC.
>
> Cheers
>
> Alex
>
>

OK, lets have a look at the 'idmap config' lines on a Unix domain
member:

idmap config *:backend = tdb
idmap config *:range = 2000-9999
## map ids from the domain the ranges may not overlap !
idmap config SAMDOM : backend = ad
idmap config SAMDOM : schema_mode = rfc2307
idmap config SAMDOM : range = 10000-999999

Now if a user has a uidNumber inside '10000-999999', or a group has a
gidNumber inside the same range AND Domain Users has a gidNumber, then
they will be shown as members of the 'SAMDOM' domain. Anything else and
this includes the Well Known SIDs shown here:

https://support.microsoft.com/en-us/help/243330/well-known-security-identifiers-in-windows-operating-systems

will be mapped to the '*' domain using the '2000-9999' range.

Just because 'getent' doesn't show the user or group, doesn't mean
winbind isn't aware who they are.

What you have to ask your self is 'does Unix have to know who this
windows user or group is ?'

Rowland

Ryan Ashley via samba

unread,
Jan 21, 2017, 7:20:03 PM1/21/17
to
I am still slightly confused here. I set these options on the domain
members (no clue how on earth to do this on a NAS) but how does it match
up? I would think the server has to have the UID/GID info so each
workstation has the same UID/GID for whatever user or group. If user A
logs into station 1 and gets the first UID there, but he is the second
user to login to station 2 he gets the second UID there. Am I missing
the big picture here?

Lead IT/IS Specialist
Reach Technology FP, Inc

Rowland Penny via samba

unread,
Jan 22, 2017, 5:10:03 AM1/22/17
to
On Sat, 21 Jan 2017 19:15:51 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

> I am still slightly confused here. I set these options on the domain
> members (no clue how on earth to do this on a NAS) but how does it
> match up? I would think the server has to have the UID/GID info so
> each workstation has the same UID/GID for whatever user or group. If
> user A logs into station 1 and gets the first UID there, but he is
> the second user to login to station 2 he gets the second UID there.
> Am I missing the big picture here?
>

Whilst you can give a workstation a uidNumber, it isn't really needed,
but if you feel you must, then you will also need to give the
workstations primary group 'Domain Computers' a gidNumber.

If you are using the winbind 'ad' backend, then (provided 'Domain
Users' has a gidNumber and the same 'idmap config' lines are used on
all Unix domain members) your users (that have a uidNumber) should get
the same UID on every Unix domain member, the same goes for groups.

There is also the winbind 'rid' backend, this calculates the user or
group ID from the user/group RID and again (provided the same 'idmap
config' lines are used on all Unix domain members) the IDs will be the
same.

The only problem with using the 'rid' backend is that it cannot be
used on a DC. This means that the only way to get the same user or
group ID on all Unix computers is to use the 'ad' backend.

I have no idea how to set up your NAS, mainly because I don't know
what NAS you are using, but you will probably have to manually edit the
smb.conf.

Ryan Ashley via samba

unread,
Jan 24, 2017, 2:00:03 PM1/24/17
to
OK, so let me get this straight in my head. I set the "idmap config"
ranges to the same range on every Unix/Linux box on the domain while NOT
setting those lines on the server itself. After that I can create new
users and give them a UID while NOT giving a UID to the built-in
accounts such as domain admin or domain guest. I then give each new
group I create a GID and the ONLY built-in group I can assign a GID to
is "Domain Users". I cannot assign a GID to "Domain Admins", "Domain
Guests", or any other group that comes with the domain. Doing this
should satisfy the *nix boxes and prevent the issue we had here. Is this
correct?

Also, I do not give machine accounts an ID, I was just using a
multi-computer setup (one named 1 and one named 2) as an example. I do
not know of any reason to assign an ID to a machine account. Then again,
I'm not Bill Gates or the Samba expert either.

Thanks for all of your help, Rowland. You've been an invaluable help
over the years.

Lead IT/IS Specialist
Reach Technology FP, Inc

Rowland Penny via samba

unread,
Jan 24, 2017, 2:10:02 PM1/24/17
to
On Tue, 24 Jan 2017 13:45:16 -0500
Ryan Ashley via samba <sa...@lists.samba.org> wrote:

> OK, so let me get this straight in my head. I set the "idmap config"
> ranges to the same range on every Unix/Linux box on the domain while
> NOT setting those lines on the server itself. After that I can create
> new users and give them a UID while NOT giving a UID to the built-in
> accounts such as domain admin or domain guest. I then give each new
> group I create a GID and the ONLY built-in group I can assign a GID to
> is "Domain Users". I cannot assign a GID to "Domain Admins", "Domain
> Guests", or any other group that comes with the domain. Doing this
> should satisfy the *nix boxes and prevent the issue we had here. Is
> this correct?

Well basically yes, except I would use 'shouldn't' instead of
'cannot', you can do it, but I wouldn't recommend it.

Ryan Ashley via samba

unread,
Jan 25, 2017, 12:00:03 PM1/25/17
to
Alright, thanks for clearing that up and helping me through this. It did
convince the client to replace the failed backup server (lightning
destroyed it years ago) so this SHOULDN'T happen again. Still, new
domain, I get to rebuild the servers, fun stuff! Going to use BTRFS
RAID1 on the two server-disks with a Gentoo install and host Samba 4 AD
DC, DNS, DHCP, and VPN on it. Hopefully between weekly SMART checks and
BTRFS on two physical systems along with the knowledge I have now we
will not hit this issue again. Thank you for all of your help!

Lead IT/IS Specialist
Reach Technology FP, Inc

0 new messages