[Samba] Rights issue on GPO

OK got it, the main difference is that ids => name mapping /is active/
on DC. So you can avoid idmap.ldb syncing if you don't use
--numeric-ids in your rsync command… as long as receiving DC "knows"
the group (name will be resolved to ID so id mismatch doesn't matter).
I think the wiki could be updated to completly remove the 4.2
statement if my assumption is correct because if receiving DC never
"saw" the BUILTIN group owning a file it'll still be mapped to the
same id as the sender… which let us in a inconsistent state

Does this work for you? Using xinetd method for rsync from the wiki user
and group mapping does not happen. Using rsync over ssh works.

achim~

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

mathias dufresne

2016-06-10 10:49:12 UTC

Thank you all for these replies.

Post by mathias dufresne
Hi all,
[snip]
And we get issue with Linux ACLs: they are not the same because some
BUILTIN users and/or groups do not have same id mapping on all DC.
How to force all DC to get same id mapping?
Using "acl_xattr:ignore system acls = yes", are Linux ACLs still important
or are we supposed to use Windows ACLs only into stored into some Samba
file? In that case, which file(s)?

They're stored in each file xattr as an obscure base64 encoded value
BUT in all cases unix permissions applies when accessing through samba.
So disabling ACLs means that you've to set the properties correctly to
allow "samba" unix users to access files (there's no clear doc on that…)
OK, first you do not need this on a DC: 'winbind nss info = rfc2307'

Secondly, your different id mappings for BUILTIN users & groups is a
well known problem. The id's are stored in 'idmap.ldb' as 'xidNumber'
attributes and seem to be given on a first come basis, only problem is, the
groups etc don't connect in the same order on every DC.

Wasn't this supposed to be solved in 4.2?
https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups
The wiki seems to say that Builtin xID are now replicated but there is no
clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will be
stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?)

Well, it is and it isn't, yes winbindd will display the user & group names
for sysvol, but sysvol still isn't replicated between DCs. I think this
means that when you sync sysvol manually, you will get the ID's from the
first DC applied to sysvol on the second DC and if there is a difference in
ID numbers between the DC's, you will either just get a number or, even
worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync on
all DCs, if you are syncing sysvol.

At least here you were right: without syncing idmap.ldb followed by "net
cache flush" Sysvol rights were an awful mess and so GPO were retrieved
once on really too few (tests are done for now with around 20 DCs which
makes that kind of issue showing really quickly/often).

I'm about to add xidNumber to any users and groups in BUILTIN and Users
directories (in LDAP tree) to avoid as often as possible that idmap
process. I should come back to tell how things went.

Rowland

To get the same ID's on every DC, you will have to copy idmap.ldb from
the first DC to every other DC, run 'net cache flush' and then keep
'idmap.ldb' in sync.
Regards

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

mathias dufresne

2016-06-10 12:12:07 UTC

One thing keep us to wonder: we added gidNumber to all groups into BUILTIN
and Users containers, my own user is in group BUILTIN/Administrators.

When id <my_user> BUILTIN/Administrators is shown with GID 7702, when
getfacl sysvol GID 3000000 is displayed as BUILTIN/Administrators.

Worst: I manually set group acl for gig 7702 on sysvol:
setfacl -m g:7702:rwx /var/lib/samba/sysvol

Then getfacl sysvol gave (samba is stopped)
# file: var/lib/samba/sysvol
# owner: root
# group: 3000000
user::rwx
user:root:rwx
user:3000000:rwx
user:3000015:r-x
user:3000019:r-x
user:3000020:rwx
group::rwx

*group:7702:rwxgroup:3000000:rwx*
group:3000015:r-x
group:3000019:r-x
group:3000020:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000000:rwx
default:user:3000015:r-x
default:user:3000019:r-x
default:user:3000020:rwx
default:group::---
default:group:3000000:rwx
default:group:3000015:r-x
default:group:3000019:r-x
default:group:3000020:rwx
default:mask::rwx
default:other::---

Samba is running:
# file: var/lib/samba/sysvol
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:3000015:r-x
user:BUILTIN\134server\040operators:r-x
user:3000020:rwx
group::rwx

*group:BUILTIN\134administrators:rwxgroup:BUILTIN\134administrators:rwx*
group:3000015:r-x
group:BUILTIN\134server\040operators:r-x
group:3000020:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:3000015:r-x
default:user:BUILTIN\134server\040operators:r-x
default:user:3000020:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:3000015:r-x
default:group:BUILTIN\134server\040operators:r-x
default:group:3000020:rwx
default:mask::rwx
default:other::---

So one group (BUILTIN\administrators), two GID (3000000 & 7702).

How to get rid of these old GID coming from idmap? I expect I can delete
idmap entry manually, I'll try that later in the afternoon I hope, but why
this entry is not removed from idmap when "net cache flush"?

Post by mathias dufresne
Thank you all for these replies.

Wasn't this supposed to be solved in 4.2?
https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups
The wiki seems to say that Builtin xID are now replicated but there is
no clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will be
stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?)

Well, it is and it isn't, yes winbindd will display the user & group
names for sysvol, but sysvol still isn't replicated between DCs. I think
this means that when you sync sysvol manually, you will get the ID's from
the first DC applied to sysvol on the second DC and if there is a
difference in ID numbers between the DC's, you will either just get a
number or, even worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync on
all DCs, if you are syncing sysvol.

At least here you were right: without syncing idmap.ldb followed by "net
cache flush" Sysvol rights were an awful mess and so GPO were retrieved
once on really too few (tests are done for now with around 20 DCs which
makes that kind of issue showing really quickly/often).
I'm about to add xidNumber to any users and groups in BUILTIN and Users
directories (in LDAP tree) to avoid as often as possible that idmap
process. I should come back to tell how things went.

Rowland

To get the same ID's on every DC, you will have to copy idmap.ldb from
the first DC to every other DC, run 'net cache flush' and then keep
'idmap.ldb' in sync.
Regards

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

mathias dufresne

2016-06-10 14:50:52 UTC

I would say it was simple:
- we gave to all groups a GID and to all users a UID and a GID (existing
GID).
- we edit manually idmap.ldb using "ldbedit -H private/idmap.ldb" to keep
inside only objects with short SID (no domain part of SID, if there is a
domain part into the SID, it is a domain object, we can define in LDAP tree
UID and/or GID)
- we change all ACLs on all sysvol files and directories (getfact -R sysvol

sysvol.acl; some sed in sysvol.acl to replace old UID/GID coming from old

idmap by the new ones coming from AD; setfacl --restore=sysvol.acl)
- then we had to replace all GID used as UID. Samba seems not to make
difference between uid and gid, at least if they come from idmap.ldb, Samba
set acl for user using groups GID...

That last part is not yet finished, we have to find out if GID used as UID
in ACL has to be replaced or deleted...

Now to explain why I get two lines for the same group in the same ACL
(which normally just can't be) it is because there was one line matching an
entry into idmap.ldb and the other line was GID coming from AD LDAP tree.
This because net cache flush does not change the content of idmap, or not
well enough. No idea yet.

After that, we are almost sure to use UID/GID from AD for every users and
groups, except for very specific users/groups as local system, local
administrator...

That link helped us greatly in that process:
https://support.microsoft.com/en-us/kb/243330
as it shows what "well-know-SID" is meant for.

Best regards,

mathias

One thing keep us to wonder: we added gidNumber to all groups into BUILTIN
and Users containers, my own user is in group BUILTIN/Administrators.
When id <my_user> BUILTIN/Administrators is shown with GID 7702, when
getfacl sysvol GID 3000000 is displayed as BUILTIN/Administrators.
setfacl -m g:7702:rwx /var/lib/samba/sysvol
Then getfacl sysvol gave (samba is stopped)
# file: var/lib/samba/sysvol
# owner: root
# group: 3000000
user::rwx
user:root:rwx
user:3000000:rwx
user:3000015:r-x
user:3000019:r-x
user:3000020:rwx
group::rwx
*group:7702:rwxgroup:3000000:rwx*
group:3000015:r-x
group:3000019:r-x
group:3000020:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000000:rwx
default:user:3000015:r-x
default:user:3000019:r-x
default:user:3000020:rwx
default:group::---
default:group:3000000:rwx
default:group:3000015:r-x
default:group:3000019:r-x
default:group:3000020:rwx
default:mask::rwx
default:other::---
# file: var/lib/samba/sysvol
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:3000015:r-x
user:BUILTIN\134server\040operators:r-x
user:3000020:rwx
group::rwx
*group:BUILTIN\134administrators:rwxgroup:BUILTIN\134administrators:rwx*
group:3000015:r-x
group:BUILTIN\134server\040operators:r-x
group:3000020:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:3000015:r-x
default:user:BUILTIN\134server\040operators:r-x
default:user:3000020:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:3000015:r-x
default:group:BUILTIN\134server\040operators:r-x
default:group:3000020:rwx
default:mask::rwx
default:other::---
So one group (BUILTIN\administrators), two GID (3000000 & 7702).
How to get rid of these old GID coming from idmap? I expect I can delete
idmap entry manually, I'll try that later in the afternoon I hope, but why
this entry is not removed from idmap when "net cache flush"?

Post by mathias dufresne
Thank you all for these replies.

Wasn't this supposed to be solved in 4.2?
https://wiki.samba.org/index.php/Join_an_additional_Samba_DC_to_an_existing_Active_Directory#GID_mappings_of_built-in_groups
The wiki seems to say that Builtin xID are now replicated but there is
no clear upgrade path (if you've mixed 4.1 & 4.2 DC which mapping will be
stored in 4.2 winbind? What happens when you upgrade the 4.1 to 4.2?)

Well, it is and it isn't, yes winbindd will display the user & group
names for sysvol, but sysvol still isn't replicated between DCs. I think
this means that when you sync sysvol manually, you will get the ID's from
the first DC applied to sysvol on the second DC and if there is a
difference in ID numbers between the DC's, you will either just get a
number or, even worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync
on all DCs, if you are syncing sysvol.

At least here you were right: without syncing idmap.ldb followed by "net
cache flush" Sysvol rights were an awful mess and so GPO were retrieved
once on really too few (tests are done for now with around 20 DCs which
makes that kind of issue showing really quickly/often).
I'm about to add xidNumber to any users and groups in BUILTIN and Users
directories (in LDAP tree) to avoid as often as possible that idmap
process. I should come back to tell how things went.

Rowland

To get the same ID's on every DC, you will have to copy idmap.ldb from
the first DC to every other DC, run 'net cache flush' and then keep
'idmap.ldb' in sync.
Regards

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

lists

2016-06-20 17:19:16 UTC

Hi all,

Following this thread with interest, as we are also having some issues
with GPO (they work on and off, unpredictably)
We checked iddap.ldb on the DCs and noticed differences between DCs.

Well, it is and it isn't, yes winbindd will display the user & group
names for sysvol, but sysvol still isn't replicated between DCs. I think
this means that when you sync sysvol manually, you will get the ID's
from the first DC applied to sysvol on the second DC and if there is a
difference in ID numbers between the DC's, you will either just get a
number or, even worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync
on all DCs, if you are syncing sysvol.

We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running on
DCs.

We understand we need to keep idmap.ldb in sync. We did this in the
past, but it seems they have gotten out of sync again.
One question: HOW OFTEN do we need to do manually sync the imap.ldb
files? After each and every regular user addition/deletion?

We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver we
are still on samba 4.2.11 and sssd. Would that last bit have any impact
on the GPO situation..? (i don't think so, because GPOs are on the DCs
and not on the fileserver..?)

Since our idmap.ldb differs per DC, HOW to choose which one to copy to
the other DCs? Choosing wrongly will probably have major implications..?

Sorry to ask so many questions, hopefully someone will answer.

Best regards,
MJ

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

l***@gmail.com

2016-06-20 17:49:45 UTC

Post by mathias dufresne
Hi all,
Following this thread with interest, as we are also having some issues
with GPO (they work on and off, unpredictably)
We checked iddap.ldb on the DCs and noticed differences between DCs.

Well, it is and it isn't, yes winbindd will display the user & group
names for sysvol, but sysvol still isn't replicated between DCs. I think
this means that when you sync sysvol manually, you will get the ID's
from the first DC applied to sysvol on the second DC and if there is a
difference in ID numbers between the DC's, you will either just get a
number or, even worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync
on all DCs, if you are syncing sysvol.

We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is running
on DCs.
We understand we need to keep idmap.ldb in sync. We did this in the
past, but it seems they have gotten out of sync again.
One question: HOW OFTEN do we need to do manually sync the imap.ldb
files? After each and every regular user addition/deletion?
We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver
we are still on samba 4.2.11 and sssd. Would that last bit have any
impact on the GPO situation..? (i don't think so, because GPOs are on
the DCs and not on the fileserver..?)
Since our idmap.ldb differs per DC, HOW to choose which one to copy to
the other DCs? Choosing wrongly will probably have major implications..?
Sorry to ask so many questions, hopefully someone will answer.
Best regards,
MJ

Mine are also out of sync. Using Samba 4.4.4 on Ubuntu 12.04. I no
longer keep the idmap.ldb in sync as I thought this was no longer needed
since version 4.2 or greater unless using winbind.

I also never would reset sysvol on the other DC's when replicating using
rsync. I don't believe it was ever in the wiki. Clarification from
someone would be helpful.

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

l***@gmail.com

2016-06-20 18:17:09 UTC

Post by mathias dufresne
Hi all,
Following this thread with interest, as we are also having some
issues with GPO (they work on and off, unpredictably)
We checked iddap.ldb on the DCs and noticed differences between DCs.

Well, it is and it isn't, yes winbindd will display the user & group
names for sysvol, but sysvol still isn't replicated between DCs. I think
this means that when you sync sysvol manually, you will get the ID's
from the first DC applied to sysvol on the second DC and if there is a
difference in ID numbers between the DC's, you will either just get a
number or, even worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync
on all DCs, if you are syncing sysvol.

We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is
running on DCs.
We understand we need to keep idmap.ldb in sync. We did this in the
past, but it seems they have gotten out of sync again.
One question: HOW OFTEN do we need to do manually sync the imap.ldb
files? After each and every regular user addition/deletion?
We are currently on sernet-4.4.4 on the 3 DCs, but on our fileserver
we are still on samba 4.2.11 and sssd. Would that last bit have any
impact on the GPO situation..? (i don't think so, because GPOs are
on the DCs and not on the fileserver..?)
Since our idmap.ldb differs per DC, HOW to choose which one to copy
to the other DCs? Choosing wrongly will probably have major
implications..?
Sorry to ask so many questions, hopefully someone will answer.
Best regards,
MJ

Mine are also out of sync. Using Samba 4.4.4 on Ubuntu 12.04. I no
longer keep the idmap.ldb in sync as I thought this was no longer
needed since version 4.2 or greater unless using winbind.
I also never would reset sysvol on the other DC's when replicating
using rsync. I don't believe it was ever in the wiki. Clarification
from someone would be helpful.

If you use Samba < 4.2.0 with the 'winbind' part of the 'samba'
binary, then you had to, but if you use Samba >= 4.2.0, then this uses
the separate 'winbindd' binary and this will map the BUILTIN users &
groups correctly.
Rowland

I completely missed the BUILTIN part. That explains my issue. That means
for all other users idmap.ldb must be kept in sync?

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

l***@gmail.com

2016-06-20 19:51:16 UTC

Post by mathias dufresne
Hi all,
Following this thread with interest, as we are also having some
issues with GPO (they work on and off, unpredictably)
We checked iddap.ldb on the DCs and noticed differences between DCs.

Well, it is and it isn't, yes winbindd will display the user & group
names for sysvol, but sysvol still isn't replicated between DCs. I think
this means that when you sync sysvol manually, you will get the ID's
from the first DC applied to sysvol on the second DC and if there is a
difference in ID numbers between the DC's, you will either just get a
number or, even worse, a wrong name returned.
I could be wrong, but I still think you need to keep idmap.ldb in sync
on all DCs, if you are syncing sysvol.

We are on sernet-samba-4.4.4 on the DCs, and "winbindd -D" is
running on DCs.
We understand we need to keep idmap.ldb in sync. We did this in
the past, but it seems they have gotten out of sync again.
One question: HOW OFTEN do we need to do manually sync the
imap.ldb files? After each and every regular user addition/deletion?
We are currently on sernet-4.4.4 on the 3 DCs, but on our
fileserver we are still on samba 4.2.11 and sssd. Would that last
bit have any impact on the GPO situation..? (i don't think so,
because GPOs are on the DCs and not on the fileserver..?)
Since our idmap.ldb differs per DC, HOW to choose which one to
copy to the other DCs? Choosing wrongly will probably have major
implications..?
Sorry to ask so many questions, hopefully someone will answer.
Best regards,
MJ

Mine are also out of sync. Using Samba 4.4.4 on Ubuntu 12.04. I no
longer keep the idmap.ldb in sync as I thought this was no longer
needed since version 4.2 or greater unless using winbind.
I also never would reset sysvol on the other DC's when replicating
using rsync. I don't believe it was ever in the wiki. Clarification
from someone would be helpful.

If you use Samba < 4.2.0 with the 'winbind' part of the 'samba'
binary, then you had to, but if you use Samba >= 4.2.0, then this
uses the separate 'winbindd' binary and this will map the BUILTIN
users & groups correctly.
Rowland

I completely missed the BUILTIN part. That explains my issue. That
means for all other users idmap.ldb must be kept in sync?

No, It seems that it now works similar to the 'rid' backend, if a user
connects to a share on the DC, that users username is used for any
files/directories created by the user.
Rowland

I'm showing inconsistent xid mappings when using winbindd. That's why I
figured I still needed to sync idmap.ldb.

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

lists

2016-06-20 18:35:14 UTC

Hi Rowland, list,

If you are using Sernet 4.4.4 packages, you must have a Sernet
subscription, you may get quicker help there.

Well I'm not sure this kind of support is included, but even if it were,
then others would not benefit from the dialogue with their support. :-)

I was wrong, if you are using 4.2.0 or later, you do not need to sync
idmap.ldb, winbindd should report the correct user/groupname.

It does do that on all DCs, yes.
...snip

default:mask::rwx
default:other::---
You should have two mapped users/groups and two unmapped ones.
Repeat on the other DCs, then open 'idmap.ldb' on each DC with ldbedit
and check that the unmapped ones are mapped to the same windows RIDs,
which should be CN=S-1-5-18 and CN=S-1-5-11

So, they are the same on DC2 and DC3, but the xid for CN=S-1-5-18 is
different on DC4 (DC4 is 3000024, compared to 3000300 on the DC2/DC3)

getfacl: Removing leading '/' from absolute path names
# file: var/lib/samba/sysvol/
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:3000009:r-x
user:OURDOMAIN\134proxmox$:rwx
group::rwx
group:BUILTIN\134server\040operators:r-x
group:BUILTIN\134administrators:rwx
group:3000009:r-x
group:OURDOMAIN\134proxmox$:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:3000009:r-x
default:user:OURDOMAIN\134proxmox$:rwx
default:group::---
default:group:BUILTIN\134server\040operators:r-x
default:group:BUILTIN\134administrators:rwx
default:group:3000009:r-x
default:group:OURDOMAIN\134proxmox$:rwx
default:mask::rwx
default:other::---

So the 'unmapped group' 3000300 has become a domain group.

I'm guessing that we need to solve this. Could you tell me how?

If they are all the same, no problem, if not, then we will come to that
if we have to :-)

Well, then if you would be so kind...? ;-)

Thanks very much Rowland!

MJ

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

2016-06-20 20:17:57 UTC

Hi,

OK, I take it that 3000009 points to CN=S-1-5-11 and it is just
CN=S-1-5-18 that is wrong by pointing at proxmox$ (which incidentally,
is one of your computers)
Try backing up idmap.ldb, then open idmap.ldb in ldbedit, find and
dn: CN=S-1-5-18
cn: S-1-5-18
objectClass: sidMap
objectSid: S-1-5-18
type: ID_TYPE_BOTH
xidNumber: 3000002 # NOTE: your number will be different!
distinguishedName: CN=S-1-5-18
Just delete it and then close & save your editor, run 'net cache flush'
and then let Samba recreate the record.

So, I did that, and output is still the same...?

I re-checked idmap.ldb on dc4, and a new entry was generated for
CN=S-1-5-18, but not with the expected xidNumber 3000300 (like on
dc2/dc3) but 3000306.

Then i searched idmap.ldb on dc4 for xidNumber 3000300, and it already

# record 295
dn: CN=S-1-5-21-90123450-981238634-861235949-133256
cn: S-1-5-21-90123450-981238634-861235949-133256
objectClass: sidMap
objectSid: S-1-5-21-90123450-981238634-861235949-133256
type: ID_TYPE_BOTH
xidNumber: 3000300
distinguishedName: CN=S-1-5-21-90123450-981238634-861235949-133256

My guess is that this is the proxmox test machine we saw in the getfacl
output on ./sysvol.

Should I simply delete that record as well..? (or am I being far too
optimistic now?)

MJ

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

2016-06-20 20:38:41 UTC

You could, but what does getfacl now show for sysvol ?
You could also try running sysvolreset on sysvol.

same output, including proxmox....
and I alreday tried that, output still the same with proxmox...

MJ

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

Achim Gottinger

2016-06-20 22:01:31 UTC

Post by lists
Hi Rowland, list,

If you are using Sernet 4.4.4 packages, you must have a Sernet
subscription, you may get quicker help there.

Well I'm not sure this kind of support is included, but even if it
were, then others would not benefit from the dialogue with their
support. :-)

Fair enough, but I would want something for my money :-D

Post by lists

I was wrong, if you are using 4.2.0 or later, you do not need to sync
idmap.ldb, winbindd should report the correct user/groupname.

It does do that on all DCs, yes.
...snip

So, they are the same on DC2 and DC3, but the xid for CN=S-1-5-18 is
different on DC4 (DC4 is 3000024, compared to 3000300 on the DC2/DC3)

So the 'unmapped group' 3000300 has become a domain group.
I'm guessing that we need to solve this. Could you tell me how?

If they are all the same, no problem, if not, then we will come to that
if we have to :-)

Well, then if you would be so kind...? ;-)
Thanks very much Rowland!
MJ

Hi MJ and Rowland,

I did abit of testing last week (two debian jesie servers with sernet
4.2 samba packages). Seems when rsync is run against rsyncd or involved
via xinet as it is described in the wiki the user and group mapping does
not work and uid and gid numbers are used. If I used rsync via ssh the
mapping works and there is no need for idmap.ldb to be in sync.

achim~

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

lists

2016-06-21 08:41:13 UTC

Hi Achim,

Post by Achim Gottinger
Hi MJ and Rowland,
I did abit of testing last week (two debian jesie servers with sernet
4.2 samba packages). Seems when rsync is run against rsyncd or involved
via xinet as it is described in the wiki the user and group mapping does
not work and uid and gid numbers are used. If I used rsync via ssh the
mapping works and there is no need for idmap.ldb to be in sync.
achim~

I have read your earlier message in this thread, yes.

Just to make sure I understand you correctly:

You are observing that rsync as a client against rsyncd DOES copy the
acls, but not by name, but by using nummerical values instead?

(like it's configured with with --numeric-ids, on the daemon or on the
client?)

If I understand things correctly, that would contradict almost all
documentation I can find on rsync / permissions and (extended) acls??

MJ

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

Achim Gottinger

2016-06-21 09:26:52 UTC

Post by lists
Hi Achim,

I have read your earlier message in this thread, yes.
You are observing that rsync as a client against rsyncd DOES copy the
acls, but not by name, but by using nummerical values instead?
(like it's configured with with --numeric-ids, on the daemon or on the
client?)
If I understand things correctly, that would contradict almost all
documentation I can find on rsync / permissions and (extended) acls??
MJ

Exactly, rsync should map user and group names if the demon on the
destination runs as root. But this does not work. I tested it with an
group named test with gid 1000 on server #1 and gid 1001 on server #2.
It works if rsync is used via ssh like this
rsync -vv -XAavz -e ssh ***@server2:/var/lib/samba/private/sysvol/
/var/lib/samba/private/sysvol/
Seems to be an issue with rsync causing trouble with sysvols.

achim~

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

lists

2016-06-21 10:10:46 UTC

Hi Achim, list,

Post by Achim Gottinger
Exactly, rsync should map user and group names if the demon on the
destination runs as root. But this does not work. I tested it with an
group named test with gid 1000 on server #1 and gid 1001 on server #2.
It works if rsync is used via ssh like this
/var/lib/samba/private/sysvol/
Seems to be an issue with rsync causing trouble with sysvols.
achim~

I just tried your suggestion, rsync over ssh vs rsync to rsyncd, and
much to my surprise, there is a difference in the resulting data?!

However unfortunately on our DC4, also rsync over ssh doesn't give us
the same getfacl output as on DC2/DC3, but it's surprising (to me) that

Post by Achim Gottinger
getfacl: Removing leading '/' from absolute path names
# file: var/lib/samba/sysvol
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:3000009:r-x
user:OURDOMAIN\134proxmox$:rwx
group::rwx
group:1078:r-x
group:BUILTIN\134administrators:rwx
group:3000009:r-x
group:OURDOMAIN\134proxmox$:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:3000009:r-x
default:user:OURDOMAIN\134proxmox$:rwx
default:group::---
default:group:1078:r-x
default:group:BUILTIN\134administrators:rwx
default:group:3000009:r-x
default:group:OURDOMAIN\134proxmox$:rwx
default:mask::rwx
default:other::---
# file: sysvol/
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:3000009:r-x
user:OURDOMAIN\134proxmox$:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:3000009:r-x
group:BUILTIN\134server\040operators:r-x
group:OURDOMAIN\134proxmox$:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:3000009:r-x
default:user:OURDOMAIN\134proxmox$:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:3000009:r-x
default:group:BUILTIN\134server\040operators:r-x
default:group:OURDOMAIN\134proxmox$:rwx
default:mask::rwx
default:other::---
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:3000009:r-x
user:3000300:rwx
group::rwx
group:BUILTIN\134server\040operators:r-x
group:BUILTIN\134administrators:rwx
group:3000009:r-x
group:3000300:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:3000009:r-x
default:user:3000300:rwx
default:group::---
default:group:BUILTIN\134server\040operators:r-x
default:group:BUILTIN\134administrators:rwx
default:group:3000009:r-x
default:group:3000300:rwx
default:mask::rwx
default:other::---

So even though your solution causes a change, our DC4 still looks not
completely healthy... Suggestions to cure our DC4 would be very much
appreciated...

But there is a much more fundamental question... how come here is
difference between (rsync over ssh) vs (rsync to rsyncd)??!

MJ

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

Achim Gottinger

2016-06-21 10:47:32 UTC

Post by lists
Hi Achim, list,

I just tried your suggestion, rsync over ssh vs rsync to rsyncd, and
much to my surprise, there is a difference in the resulting data?!
However unfortunately on our DC4, also rsync over ssh doesn't give us
the same getfacl output as on DC2/DC3, but it's surprising (to me)

So even though your solution causes a change, our DC4 still looks not
completely healthy... Suggestions to cure our DC4 would be very much
appreciated...
But there is a much more fundamental question... how come here is
difference between (rsync over ssh) vs (rsync to rsyncd)??!
MJ

Looks like on DC4 3000300 is mapped to an computer account for "proxmox".

On DC2/DC32 3000009 should map to S-1-5-18 (Local System) and 3000300
S-1-5-11 (Autheticated Users).
These are both Security groups which do not resolv via winbindd so they
can not be mapped. (you may add manual mapping via the --groupmap on
your rsync commandline).

I assume you can delete the mapping for 3000300 on dc4 and change the
mapping for S-1-5-11 to 3000300 (and S-1-5-18 to 3000009 if that id is
not used by something else) in idmap.ldb on DC4. After an cache flush
sync things should work again.

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

lists

2016-06-21 11:09:55 UTC

Hi Achim,

Post by Achim Gottinger
Looks like on DC4 3000300 is mapped to an computer account for "proxmox".
On DC2/DC32 3000009 should map to S-1-5-18 (Local System) and 3000300
S-1-5-11 (Autheticated Users).
These are both Security groups which do not resolv via winbindd so they
can not be mapped. (you may add manual mapping via the --groupmap on
your rsync commandline).
I assume you can delete the mapping for 3000300 on dc4 and change the
mapping for S-1-5-11 to 3000300 (and S-1-5-18 to 3000009 if that id is
not used by something else) in idmap.ldb on DC4. After an cache flush
sync things should work again.

I took a backup of the dc4 kvm, and followed the procedure on the wiki
to copy the idmap.ldb from DC2 to DC4. (a bit more drastical, but it
seems to have worked out also)

Then YOUR sysvol sync method, over ssh, and now the permissions look
good on DC4.

Thanks!

MJ

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

l***@gmail.com

2016-06-21 14:48:21 UTC

Post by lists
Hi Achim,

I took a backup of the dc4 kvm, and followed the procedure on the wiki
to copy the idmap.ldb from DC2 to DC4. (a bit more drastical, but it
seems to have worked out also)
Then YOUR sysvol sync method, over ssh, and now the permissions look
good on DC4.
Thanks!
MJ

I found my issue. On one of my DC's I had misspelled 'idmap_ldb:use
rfc2307 = Yes'. I had it 'idmap_lbd:'. Ran 'net cache flush' and wbinfo
gave correct mappings. I find it odd that 'samba-tool testparm' never
threw any errors.

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

2016-06-22 09:13:14 UTC

Post by l***@gmail.com
I found my issue. On one of my DC's I had misspelled 'idmap_ldb:use
rfc2307 = Yes'. I had it 'idmap_lbd:'. Ran 'net cache flush' and wbinfo
gave correct mappings. I find it odd that 'samba-tool testparm' never
threw any errors.

I am under the impression that on a DC:
idmap_ldb:use rfc2307 = Yes
is not required at all?

(but please correct me if I'm wrong)

MJ

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

2016-06-22 11:44:12 UTC

Happy to correct you :-D
If you are using RFC2307 attributes, you need this line on a DC, it is
*only* used on a DC.

Right... Thanks!

And then perhaps we also need to set the idmap ranges on the DCs? I
thought they were only for the domain member servers...

MJ

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

2016-06-22 11:59:27 UTC

Post by mj
And then perhaps we also need to set the idmap ranges on the DCs? I
thought they were only for the domain member servers...

https://wiki.samba.org/index.php/Setting_up_RFC2307_in_AD

:-)

--
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

2016-06-22 12:19:21 UTC

And dont forget :
https://wiki.samba.org/index.php/Idmap_config_ad

I also noticed and incorrect mapping, which "looks" like rights issues like in the thead here. ( it is imo not a right issue.. ) read on..

NTDOMAIN\enterprise read-only domain controllers:x:3000202:
NTDOMAIN\domain admins:x:10001:NTDOMAIN\administrator
NTDOMAIN\domain users:x:10000:
NTDOMAIN\domain guests:x:10002:
NTDOMAIN\domain computers:x:10006:
NTDOMAIN\domain controllers:x:3000018:
NTDOMAIN\read-only domain controllers:x:3000203:

Is conflicting with
BUILTIN\administrators:x:3000000:
BUILTIN\users:x:3000009:
BUILTIN\guests:x:3000015:
BUILTIN\account operators:x:3000185:
BUILTIN\server operators:x:3000001:

Which results in some incorrect mappings.

But if you add : acl_xattr:ignore system acls = yes to the Sysvol share.
!! AND your using the DC's only as DC's. !!

Then this incorrect mapping can be ignored, at least im ignoring it,
since very thing is tested and works fine.

But im thinking of settings a separated range for the BUILDIN

A setup something like :

idmap_ldb:use rfc2307 = yes

## map id's outside to domain to tdb files.
## use for local (linux only ) users
idmap config * : backend = tdb
idmap config * : range = 2000-9999

## map ids from the domain and (*) the range may not overlap !
## the NTDOMAIN range id mappings
idmap config NTDOMAIN : backend = ad
idmap config NTDOMAIN : schema_mode = rfc2307
idmap config NTDOMAIN : range = 10000-2999999

## map ids from BUILDIN ( LOCAL SYSTEM )
##
idmap config BUILDIN : backend = ad
idmap config BUILDIN : schema_mode = rfc2307
idmap config BUILDIN : range = 3000000-3999999

Sometimes, and if you see from within windows security rights like :
NTDOMAIN\administrators
Which should be
BUILDIN\administrators

Anyone any suggestion about setting an extra BUILDIN range for the Local Computer/System.

Greetz,

Louis

-----Oorspronkelijk bericht-----
Verzonden: woensdag 22 juni 2016 13:59
Onderwerp: Re: [Samba] Rights issue on GPO

Post by mj
And then perhaps we also need to set the idmap ranges on the DCs? I
thought they were only for the domain member servers...

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

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

l***@gmail.com

2016-06-22 12:44:18 UTC

Post by L.P.H. van Belle
https://wiki.samba.org/index.php/Idmap_config_ad
I also noticed and incorrect mapping, which "looks" like rights issues like in the thead here. ( it is imo not a right issue.. ) read on..
NTDOMAIN\domain admins:x:10001:NTDOMAIN\administrator
Is conflicting with
Which results in some incorrect mappings.
But if you add : acl_xattr:ignore system acls = yes to the Sysvol share.
!! AND your using the DC's only as DC's. !!
Then this incorrect mapping can be ignored, at least im ignoring it,
since very thing is tested and works fine.
But im thinking of settings a separated range for the BUILDIN
idmap_ldb:use rfc2307 = yes
## map id's outside to domain to tdb files.
## use for local (linux only ) users
idmap config * : backend = tdb
idmap config * : range = 2000-9999
## map ids from the domain and (*) the range may not overlap !
## the NTDOMAIN range id mappings
idmap config NTDOMAIN : backend = ad
idmap config NTDOMAIN : schema_mode = rfc2307
idmap config NTDOMAIN : range = 10000-2999999
## map ids from BUILDIN ( LOCAL SYSTEM )
##
idmap config BUILDIN : backend = ad
idmap config BUILDIN : schema_mode = rfc2307
idmap config BUILDIN : range = 3000000-3999999
NTDOMAIN\administrators
Which should be
BUILDIN\administrators
Anyone any suggestion about setting an extra BUILDIN range for the Local Computer/System.
Greetz,
Louis

-----Oorspronkelijk bericht-----
Verzonden: woensdag 22 juni 2016 13:59
Onderwerp: Re: [Samba] Rights issue on GPO

Post by mj
And then perhaps we also need to set the idmap ranges on the DCs? I
thought they were only for the domain member servers...

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

Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

getfacl: Removing leading '/' from absolute path names
# file: usr/local/samba/var/locks/sysvol/
# owner: root
# group: 3000000
user::rwx
user:root:rwx
user:3000000:rwx
user:3000001:r-x
user:3000002:rwx
user:3000003:r-x
group::rwx
group:3000000:rwx
group:3000001:r-x
group:3000002:rwx
group:3000003:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000000:rwx
default:user:3000001:r-x
default:user:3000002:rwx
default:user:3000003:r-x
default:group::---
default:group:3000000:rwx
default:group:3000001:r-x
default:group:3000002:rwx
default:group:3000003:r-x
default:mask::rwx
default:other::---

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

2016-06-22 12:53:16 UTC

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

do you have winbind in /etc/nsswitch.conf?

mj

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

l***@gmail.com

2016-06-22 13:09:10 UTC

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

do you have winbind in /etc/nsswitch.conf?
mj

No.

cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: compat
group: compat
shadow: compat

hosts: files dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

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

l***@gmail.com

2016-06-22 13:09:52 UTC

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

do you have winbind in /etc/nsswitch.conf?
mj

I also thought winbind was only necessary on member servers.

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

mathias dufresne

2016-06-22 13:30:57 UTC

@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system acls = yes" as shown
on the first mail of that thread. And even using that rights errors on GPO
files _are_ an issue. Otherwise that thread won't have been opened of
course : )

Regarding how we decided to workaround almost definitively with that was to
give every users and groups in AD some xID, also those in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside only special users /
groups (as "local system" / S-1-5-18, "guests" / S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized on all our DC, for
these special items have same mapped xID in case they are used (and so
mapped).

Doing that id mapper has no reason to define by itself some xID to users
and groups contained into AD as they already have some xID.

Until now it seems to work fine...

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

do you have winbind in /etc/nsswitch.conf?
mj

I also thought winbind was only necessary on member servers.
--
-James
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

--
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

2016-06-22 14:31:13 UTC

My understanding also.. but on an ADDC .
When your typing to test :

getent passwd ( needs nsswitch.conf changed )
id username ( needs nsswitch.conf changed )

wbinfo -u No changes needed.

Just depends what you want to see when and where..

Greetz,

Louis

-----Oorspronkelijk bericht-----
Verzonden: woensdag 22 juni 2016 16:13
Onderwerp: Re: [Samba] Rights issue on GPO

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

do you have winbind in /etc/nsswitch.conf?
mj

I also thought winbind was only necessary on member servers.

MY understanding is that you need winbind in /etc/nsswitch.conf whenever
you want AD users or groups to be known to the underlying Unix OS.
Rowland
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

--
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

2016-06-22 14:37:24 UTC

@Mathias,

Pretty strange then, running some years like this without any problem.
Yes we had few problems with "rights" in sysvol, but i fixed this all outside linux, and with that i mean. Changed rights from within windows or added registry changes or patches, or a local clean up of the policies.

At the install of my DC2 i also synced the idmap.ldb, and then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.

All new added, but i'll keep an eye also in this and i'll recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".

Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)

Gr.

Louis

-----Oorspronkelijk bericht-----
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system acls = yes" as shown
on the first mail of that thread. And even using that rights errors on GPO
files _are_ an issue. Otherwise that thread won't have been opened of
course : )
Regarding how we decided to workaround almost definitively with that was
to
give every users and groups in AD some xID, also those in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside only special users
/
groups (as "local system" / S-1-5-18, "guests" / S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized on all our DC, for
these special items have same mapped xID in case they are used (and so
mapped).
Doing that id mapper has no reason to define by itself some xID to users
and groups contained into AD as they already have some xID.
Until now it seems to work fine...

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN like
others?

do you have winbind in /etc/nsswitch.conf?
mj

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

mathias dufresne

2016-06-22 16:21:03 UTC

OK you keep idmap.ldb synched, that's what I missed until few days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID is only to
avoid usage of mapping. I expect the synchronization of idmap.ldb (if done
often enough) would be sufficient. But I don't always like magic : )

Thank you for precisions !

Cheers all

Post by L.P.H. van Belle

-----Oorspronkelijk bericht-----

dufresne

Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system acls = yes" as shown
on the first mail of that thread. And even using that rights errors on

GPO

files _are_ an issue. Otherwise that thread won't have been opened of
course : )
Regarding how we decided to workaround almost definitively with that was to
give every users and groups in AD some xID, also those in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside only special users /
groups (as "local system" / S-1-5-18, "guests" / S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized on all our DC, for
these special items have same mapped xID in case they are used (and so
mapped).
Doing that id mapper has no reason to define by itself some xID to users
and groups contained into AD as they already have some xID.
Until now it seems to work fine...

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN

Post by l***@gmail.com
others?

do you have winbind in /etc/nsswitch.conf?
mj

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

l***@gmail.com

2016-06-24 13:24:04 UTC

Post by mathias dufresne

Post by L.P.H. van Belle

-----Oorspronkelijk bericht-----

dufresne

GPO

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN

Post by l***@gmail.com
others?

do you have winbind in /etc/nsswitch.conf?
mj

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

If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?

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

mathias dufresne

2016-06-24 15:40:18 UTC

Post by L.P.H. van Belle
@Mathias,

Post by L.P.H. van Belle
Pretty strange then, running some years like this without any problem.
Yes we had few problems with "rights" in sysvol, but i fixed this all
outside linux, and with that i mean. Changed rights from within windows or
added registry changes or patches, or a local clean up of the policies.
At the install of my DC2 i also synced the idmap.ldb, and then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few days and

was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID is only to
avoid usage of mapping. I expect the synchronization of idmap.ldb (if done
often enough) would be sufficient. But I don't always like magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----

Post by L.P.H. van Belle
dufresne

GPO

files _are_ an issue. Otherwise that thread won't have been opened of
course : )
Regarding how we decided to workaround almost definitively with that was to
give every users and groups in AD some xID, also those in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside only special users
/
groups (as "local system" / S-1-5-18, "guests" / S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized on all our DC, for
these special items have same mapped xID in case they are used (and so
mapped).
Doing that id mapper has no reason to define by itself some xID to users
and groups contained into AD as they already have some xID.
Until now it seems to work fine...

Post by l***@gmail.com
Why is is when I do a getfacl I do not see the mapping of BUILTIN
like

others?

Post by mj
do you have winbind in /etc/nsswitch.conf?

mj
I also thought winbind was only necessary on member servers.

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

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

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

If I assign every user a UID and select groups a GID by utilizing rfc2307
on my DC's. Would I still benefit from keeping idmap.ldb synchronized? I'm
thinking XID's are obsolete at that point?

Only users and groups in AD will avoid id mapper by that workaround. But
there are others accounts ("local system", "guest", "local
administrator"...) all these accounts exist on MS Windows clients, and so
they can all do stuff on Sysvol and so they can all go through id mapper.

So no. There no way (for me at least :) to totally avoid id mapper and so
you should keep idmap.ldb synched.

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

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

l***@gmail.com

2016-06-24 18:47:02 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID is only to
avoid usage of mapping. I expect the synchronization of idmap.ldb (if done
often enough) would be sufficient. But I don't always like magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some xID.
Until now it seems to work fine...
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that workaround.
But there are others accounts ("local system", "guest", "local
administrator"...) all these accounts exist on MS Windows clients, and
so they can all do stuff on Sysvol and so they can all go through id
mapper.
So no. There no way (for me at least :) to totally avoid id mapper and
so you should keep idmap.ldb synched.
--
-James
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb. Does
anyone have one at the moment? Is it best practice to stop samba before
replacing idmap.ldb on the additional DC's? My script will currently
watch for any idmap.ldb changes and create a hot backup if a change is
detected. It will then send to the other DC's via rsync. I'm thinking
starting and stopping samba isn't ideal during production hours.

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

Achim Gottinger

2016-06-24 20:35:09 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
instructions: https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that workaround.
But there are others accounts ("local system", "guest", "local
administrator"...) all these accounts exist on MS Windows clients,
and so they can all do stuff on Sysvol and so they can all go
through id mapper.
So no. There no way (for me at least :) to totally avoid id mapper
and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following URL and
read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb. Does
anyone have one at the moment? Is it best practice to stop samba
before replacing idmap.ldb on the additional DC's? My script will
currently watch for any idmap.ldb changes and create a hot backup if
a change is detected. It will then send to the other DC's via rsync.
I'm thinking starting and stopping samba isn't ideal during
production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd' binary,
there is no reason to sync idmap.ldb. Syncing idmap was/is only
required if you use 'winbind' that is built into the 'samba' binary.
Rowland

Hello Rowland,

If you take an look on your sysvol rights there are two still unresoved
groups SECURITY\Local System and SECURITY\Autheticated Users. These show
up with gid's from idmap.ldb in the acl list and therefore can not be
mapped during rsync. So at least these two groups need idntical mapping
on all dc's. It is however not neccessary to keep idmap in sync as long
as no ther security groups are used.

achim~

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

Achim Gottinger

2016-06-24 21:08:12 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system", "guest",
"local administrator"...) all these accounts exist on MS Windows
clients, and so they can all do stuff on Sysvol and so they can all
go through id mapper.
So no. There no way (for me at least :) to totally avoid id mapper
and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following URL
and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb. Does
anyone have one at the moment? Is it best practice to stop samba
before replacing idmap.ldb on the additional DC's? My script will
currently watch for any idmap.ldb changes and create a hot backup if
a change is detected. It will then send to the other DC's via rsync.
I'm thinking starting and stopping samba isn't ideal during
production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap was/is
only required if you use 'winbind' that is built into the 'samba'
binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list and
therefore can not be mapped during rsync. So at least these two groups
need idntical mapping on all dc's. It is however not neccessary to
keep idmap in sync as long as no ther security groups are used.
achim~

To be more specific the groups belongig to "WellKnown Security
Principals" are not mapped. I called them security groups above.
See here for an list:
https://technet.microsoft.com/en-us/library/dn617202(v=ws.11).aspx#BKMK_AuthenticatedUser

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

Achim Gottinger

2016-06-25 14:11:46 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb
synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on MS
Windows clients, and so they can all do stuff on Sysvol and so
they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following URL
and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to stop
samba before replacing idmap.ldb on the additional DC's? My script
will currently watch for any idmap.ldb changes and create a hot
backup if a change is detected. It will then send to the other
DC's via rsync. I'm thinking starting and stopping samba isn't
ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap was/is
only required if you use 'winbind' that is built into the 'samba'
binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list and
therefore can not be mapped during rsync. So at least these two
groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security groups
are used.
achim~

To be more specific the groups belongig to "WellKnown Security
Principals" are not mapped. I called them security groups above.
https://technet.microsoft.com/en-us/library/dn617202(v=ws.11).aspx#BKMK_AuthenticatedUser

I know all of the above, and you seem to be using fixes that had to be
used with a Samba 4 AD DC that used the 'winbind' part of the 'samba'
binary.
When Samba 4.2.0 came out, 'winbind' was replaced with the separate
'winbindd' binary (the same one used on a domain member). This means
that, even though an AD object may be mapped to a number, the DC knows
what AD object that is.
This means you do not need to sync idmap.ldb between DCs if you use
Samba >= 4.2.0 with the separate 'winbindd' binary.
Rowland

Look at my other posts today, there are still interferences between the
posix acls and the xattr acl's whom can cause sysvol to be not
accessible or accessible or even writeable by unwanted groups. Did my
tests on debian jessie using sernet 4.2 packages.

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

mathias dufresne

2016-06-26 11:50:25 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the

https://lists.samba.org/mailman/options/samba

Post by L.P.H. van Belle
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that workaround.

But there are others accounts ("local system", "guest", "local
administrator"...) all these accounts exist on MS Windows clients, and so
they can all do stuff on Sysvol and so they can all go through id mapper.

Post by L.P.H. van Belle
So no. There no way (for me at least :) to totally avoid id mapper

and so you should keep idmap.ldb synched.

Post by L.P.H. van Belle
-- -James
-- To unsubscribe from this list go to the following URL and

read the

Post by L.P.H. van Belle
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb. Does

anyone have one at the moment? Is it best practice to stop samba before
replacing idmap.ldb on the additional DC's? My script will currently watch
for any idmap.ldb changes and create a hot backup if a change is detected.
It will then send to the other DC's via rsync. I'm thinking starting and
stopping samba isn't ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd' binary,

there is no reason to sync idmap.ldb. Syncing idmap was/is only required if
you use 'winbind' that is built into the 'samba' binary.

Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still unresoved

groups SECURITY\Local System and SECURITY\Autheticated Users. These show up
with gid's from idmap.ldb in the acl list and therefore can not be mapped
during rsync. So at least these two groups need idntical mapping on all
dc's. It is however not neccessary to keep idmap in sync as long as no ther
security groups are used.

Post by Achim Gottinger
achim~

To be more specific the groups belongig to "WellKnown Security

Principals" are not mapped. I called them security groups above.
https://technet.microsoft.com/en-us/library/dn617202(v=ws.11).aspx#BKMK_AuthenticatedUser

I know all of the above, and you seem to be using fixes that had to be

used with a Samba 4 AD DC that used the 'winbind' part of the 'samba'
binary.

When Samba 4.2.0 came out, 'winbind' was replaced with the separate

'winbindd' binary (the same one used on a domain member). This means that,
even though an AD object may be mapped to a number, the DC knows what AD
object that is.

This means you do not need to sync idmap.ldb between DCs if you use Samba
= 4.2.0 with the separate 'winbindd' binary.

What you wrote sounds very strange to me as we use 4.4.4, we do not specify
explicitly Samba to use winbind in place of winbindd, and we had to keep
idmap.ldb synced. Or at least we had issues until we synced it.

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

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

Achim Gottinger

2016-06-24 21:16:34 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on MS
Windows clients, and so they can all do stuff on Sysvol and so
they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id mapper
and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following URL
and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb. Does
anyone have one at the moment? Is it best practice to stop samba
before replacing idmap.ldb on the additional DC's? My script will
currently watch for any idmap.ldb changes and create a hot backup
if a change is detected. It will then send to the other DC's via
rsync. I'm thinking starting and stopping samba isn't ideal during
production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap was/is
only required if you use 'winbind' that is built into the 'samba'
binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list and
therefore can not be mapped during rsync. So at least these two
groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security groups
are used.
achim~

Yes I know, but each DC knows who they are and as they are members of
the 'SECURITY' domain, they aren't mapped to the DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server (dc1) ist
used for some "random group" on the target server (dc2), the read right
on sysvol for authenticated users will instead be given to "random
group". This can result in users not a member of "random group" will not
be able to access content on sysvol. Therefore it is mandatory that
these security groups are mapped to the same gid on all dc's the sysvol
conted is replicated.

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

Achim Gottinger

2016-06-25 00:21:37 UTC

Post by L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb
synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on MS
Windows clients, and so they can all do stuff on Sysvol and so
they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following URL
and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to stop
samba before replacing idmap.ldb on the additional DC's? My script
will currently watch for any idmap.ldb changes and create a hot
backup if a change is detected. It will then send to the other
DC's via rsync. I'm thinking starting and stopping samba isn't
ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap was/is
only required if you use 'winbind' that is built into the 'samba'
binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list and
therefore can not be mapped during rsync. So at least these two
groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security groups
are used.
achim~

Yes I know, but each DC knows who they are and as they are members of
the 'SECURITY' domain, they aren't mapped to the DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server (dc1)
ist used for some "random group" on the target server (dc2), the read
right on sysvol for authenticated users will instead be given to
"random group". This can result in users not a member of "random
group" will not be able to access content on sysvol. Therefore it is
mandatory that these security groups are mapped to the same gid on all
dc's the sysvol conted is replicated.

This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN in
4.2 has no impact but I assume the ACL's are read from the
security.NTACL xattr so "Authenticated Users" should always have access
because the xattr stores SID's and not the xid's. xattrs should be
replicated with rsync without any mapping required.

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

Achim Gottinger

2016-06-25 10:35:09 UTC

2016-06-22 16:37 GMT+02:00 L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the
idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb
synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the
following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on
MS Windows clients, and so they can all do stuff on Sysvol and
so they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following URL
and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to stop
samba before replacing idmap.ldb on the additional DC's? My
script will currently watch for any idmap.ldb changes and create
a hot backup if a change is detected. It will then send to the
other DC's via rsync. I'm thinking starting and stopping samba
isn't ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap was/is
only required if you use 'winbind' that is built into the 'samba'
binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list and
therefore can not be mapped during rsync. So at least these two
groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security groups
are used.
achim~

Yes I know, but each DC knows who they are and as they are members
of the 'SECURITY' domain, they aren't mapped to the DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server (dc1)
ist used for some "random group" on the target server (dc2), the read
right on sysvol for authenticated users will instead be given to
"random group". This can result in users not a member of "random
group" will not be able to access content on sysvol. Therefore it is
mandatory that these security groups are mapped to the same gid on
all dc's the sysvol conted is replicated.

This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN in
4.2 has no impact but I assume the ACL's are read from the
security.NTACL xattr so "Authenticated Users" should always have
access because the xattr stores SID's and not the xid's. xattrs should
be replicated with rsync without any mapping required.

Did an short test if proper posix uid/gid mapping is required for sysvol
to work.
Since vfs_acl_xattr is in use samba is said to keep the posix acl's in
sync with the acl's stored in the security.NTACL xattr object.
(https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html)
If i sync from an dc with different mappings in idmap.ldb the posix
acl's seem to have precedence over the xattr values, so they can mess up
things in an way that some security groups can gain read or ever write
rights because of the different mappings.
An easy fix is adding
acl_xattr:ignore system acls = Yes
to the sysvol section in smb.conf. Posix ACL's are now ignored and only
the ACL's from the xattr are used.

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

Achim Gottinger

2016-06-26 11:43:24 UTC

Created an feature request

"add resolving for well known security principals"

https://bugzilla.samba.org/show_bug.cgi?id=11997

2016-06-22 16:37 GMT+02:00 L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the
idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in /etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the
following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on
MS Windows clients, and so they can all do stuff on Sysvol and
so they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following
URL and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to stop
samba before replacing idmap.ldb on the additional DC's? My
script will currently watch for any idmap.ldb changes and create
a hot backup if a change is detected. It will then send to the
other DC's via rsync. I'm thinking starting and stopping samba
isn't ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap
was/is only required if you use 'winbind' that is built into the
'samba' binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list and
therefore can not be mapped during rsync. So at least these two
groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security
groups are used.
achim~

Yes I know, but each DC knows who they are and as they are members
of the 'SECURITY' domain, they aren't mapped to the DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server (dc1)
ist used for some "random group" on the target server (dc2), the
read right on sysvol for authenticated users will instead be given
to "random group". This can result in users not a member of "random
group" will not be able to access content on sysvol. Therefore it is
mandatory that these security groups are mapped to the same gid on
all dc's the sysvol conted is replicated.

This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN
in 4.2 has no impact but I assume the ACL's are read from the
security.NTACL xattr so "Authenticated Users" should always have
access because the xattr stores SID's and not the xid's. xattrs
should be replicated with rsync without any mapping required.

Did an short test if proper posix uid/gid mapping is required for
sysvol to work.
Since vfs_acl_xattr is in use samba is said to keep the posix acl's in
sync with the acl's stored in the security.NTACL xattr object.
(https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html)
If i sync from an dc with different mappings in idmap.ldb the posix
acl's seem to have precedence over the xattr values, so they can mess
up things in an way that some security groups can gain read or ever
write rights because of the different mappings.
An easy fix is adding
acl_xattr:ignore system acls = Yes
to the sysvol section in smb.conf. Posix ACL's are now ignored and
only the ACL's from the xattr are used.

--
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

2016-06-27 12:26:25 UTC

Hai,

After lots of testing and checking today im must concluded that achim and mathias are right.
There are "BUILDIN\" security groups which make some GPOs are going wrong.

Also, im getting errors again with sysvolcheck. .. i was in the understanding this was resolved.. but im but off with all info, very buzy at the office atm.

samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught exception - ProvisioningError: DB ACL on GPO directory /home/samba/sysvol/domain/Policies/{EAF212FE-4718-4693-BD18-6B4FC8A0513A} O:LAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) does not match expected value O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED) from GPO object
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 175, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 270, in run
lp)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1732, in checksysvolacl
direct_db_access)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1683, in check_gpos_acl
domainsid, direct_db_access)
File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1630, in check_dir_acl
raise ProvisioningError('%s ACL on GPO directory %s %s does not match expected value %s from GPO object' % (acl_type(direct_db_access), path, fsacl_sddl, acl))

running debian samba 4.4.3 jessie.
I was running without problems with 4.2.9 and 4.3.6.
I can tell about the higher versions after the badlock bug i've updated to 4.4.3 on all machines.

Rowland, can you make a custom policy, apply a own defined group the security filter. ( any random user policy )
Run gpupdate /force
Run gpresult /h:Path/Yourresult.html
Now check the result.html

Im getting lots of..
{CLID} domain.test.tld/Office/Locaiotn Not accessable

And these where working fine for more then a year now.

Greetz,

Louis

-----Oorspronkelijk bericht-----
Verzonden: maandag 27 juni 2016 14:08
Onderwerp: Re: [Samba] Rights issue on GPO

Post by Achim Gottinger
Created an feature request
"add resolving for well known security principals"
https://bugzilla.samba.org/show_bug.cgi?id=11997

2016-06-22 16:37 GMT+02:00 L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the
idmap.ldb, and
then a
net idmap flush on both servers to make my both
dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
2016-06-22 15:09 GMT+02:00
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in
/etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the
following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on
MS Windows clients, and so they can all do stuff on Sysvol and
so they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following
URL and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to stop
samba before replacing idmap.ldb on the additional DC's? My
script will currently watch for any idmap.ldb changes and
create a hot backup if a change is detected. It will then send
to the other DC's via rsync. I'm thinking starting and stopping
samba isn't ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap
was/is only required if you use 'winbind' that is built into the
'samba' binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list
and therefore can not be mapped during rsync. So at least these
two groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security
groups are used.
achim~

Yes I know, but each DC knows who they are and as they are members
of the 'SECURITY' domain, they aren't mapped to the DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server
(dc1) ist used for some "random group" on the target server (dc2),
the read right on sysvol for authenticated users will instead be
given to "random group". This can result in users not a member of
"random group" will not be able to access content on sysvol.
Therefore it is mandatory that these security groups are mapped to
the same gid on all dc's the sysvol conted is replicated.

This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN
in 4.2 has no impact but I assume the ACL's are read from the
security.NTACL xattr so "Authenticated Users" should always have
access because the xattr stores SID's and not the xid's. xattrs
should be replicated with rsync without any mapping required.

Did an short test if proper posix uid/gid mapping is required for
sysvol to work.
Since vfs_acl_xattr is in use samba is said to keep the posix acl's
in sync with the acl's stored in the security.NTACL xattr object.
(https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html)
If i sync from an dc with different mappings in idmap.ldb the posix
acl's seem to have precedence over the xattr values, so they can mess
up things in an way that some security groups can gain read or ever
write rights because of the different mappings.
An easy fix is adding
acl_xattr:ignore system acls = Yes
to the sysvol section in smb.conf. Posix ACL's are now ignored and
only the ACL's from the xattr are used.

OK, I finally got round to installing win10 in a VM on my new computer,
so I have been able to fully test 'sysvol' on both DCs.
getfacl: Removing leading '/' from absolute path names
# file: usr/local/samba/var/locks/sysvol/
# owner: root
# group: BUILTIN\134administrators
# flags: -s-
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:BUILTIN\134server\040operators:r-x
group:3000002:rwx
group:3000003:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:BUILTIN\134server\040operators:r-x
default:group:3000002:rwx
default:group:3000003:r-x
default:mask::rwx
default:other::---
getfacl: Removing leading '/' from absolute path names
# file: usr/local/samba/var/locks/sysvol/
# owner: root
# group: BUILTIN\134administrators
# flags: -s-
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:BUILTIN\134server\040operators:r-x
user:3000014:r-x
user:3000030:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:BUILTIN\134server\040operators:r-x
group:3000014:r-x
group:3000030:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:BUILTIN\134server\040operators:r-x
default:user:3000014:r-x
default:user:3000030:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:BUILTIN\134server\040operators:r-x
default:group:3000014:r-x
default:group:3000030:rwx
default:mask::rwx
default:other::---
group:3000002:rwx
group:3000003:r-x
The first is for the SID 'CN=S-1-5-18' , this is 'Local System', the
second is for the SID 'CN=S-1-5-11', this is 'Authenticated Users'
group:3000014:r-x
group:3000030:rwx
The first is for the SID 'CN=S-1-5-11' this is 'Authenticated Users',
the second is for the SID 'CN=S-1-5-18' , this is 'Local System'
Administrators
Server Operators
Local System
Authenticated Users
Administrators
Server Operators
Authenticated Users
Local System
So, from the Unix point of view, 'sysvol' belongs to the correct
users/groups, but what about windows ?
If I navigate to each DC on win10, select the 'sysvol' share and
Authenticated Users
SYSTEM
Administrators
Server Operators
The same as on the DCs.
I do not 'sync' idmap.ldb and the DCs are both running 4.4.3
Bearing in mind the above, why are people still syncing 'idmap.ldb' if
they are using the separate 'winbindd' binary ??
The only slight 'problem' that I can see, getfacl seems to return
different results depending on which DC it is run on, the same basic
result, but on one it is a user and on the other it is a group.
Rowland
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

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

l***@gmail.com

2016-06-27 12:53:31 UTC

Post by L.P.H. van Belle
Hai,
After lots of testing and checking today im must concluded that achim
and mathias are right.
There are "BUILDIN\" security groups which make some GPOs are going wrong.
Also, im getting errors again with sysvolcheck. .. i was in the
understanding this was resolved.. but im but off with all info, very
buzy at the office atm.
samba-tool ntacl sysvolcheck
ERROR(<class 'samba.provision.ProvisioningError'>): uncaught
exception - ProvisioningError: DB ACL on GPO directory
/home/samba/sysvol/domain/Policies/{EAF212FE-4718-4693-BD18-6B4FC8A0513A}
O:LAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
does not match expected value
O:DAG:DAD:PAR(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;EA)(A;OICIIO;0x001f01ff;;;CO)(A;OICI;0x001f01ff;;;DA)(A;OICI;0x001f01ff;;;SY)(A;OICI;0x001200a9;;;AU)(A;OICI;0x001200a9;;;ED)
from GPO object
File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 175, in _run
return self.run(*args, **kwargs)
File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 270, in run
lp)
File
"/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line
1732, in checksysvolacl
direct_db_access)
File
"/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line
1683, in check_gpos_acl
domainsid, direct_db_access)
File
"/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line
1630, in check_dir_acl
raise ProvisioningError('%s ACL on GPO directory %s %s does not
match expected value %s from GPO object' %
(acl_type(direct_db_access), path, fsacl_sddl, acl))
running debian samba 4.4.3 jessie.
I was running without problems with 4.2.9 and 4.3.6.
I can tell about the higher versions after the badlock bug i've
updated to 4.4.3 on all machines.
Rowland, can you make a custom policy, apply a own defined group the
security filter. ( any random user policy )
Run gpupdate /force
Run gpresult /h:Path/Yourresult.html
Now check the result.html
Im getting lots of..
{CLID} domain.test.tld/Office/Locaiotn Not accessable
And these where working fine for more then a year now.
Greetz,
Louis

-----Oorspronkelijk bericht-----
Verzonden: maandag 27 juni 2016 14:08
Onderwerp: Re: [Samba] Rights issue on GPO

Post by Achim Gottinger
Created an feature request
"add resolving for well known security principals"
https://bugzilla.samba.org/show_bug.cgi?id=11997

2016-06-22 16:37 GMT+02:00 L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this
without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local
clean up of
the policies.
At the install of my DC2 i also synced the
idmap.ldb, and
then a
net idmap flush on both servers to make my both
dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this
and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed
until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD
some xID
is only to
avoid usage of mapping. I expect the
synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
Van: samba
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even
using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread
won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID,
also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to
keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb
synchronized
on all our DC, for
these special items have same mapped xID in
case they
are used (and so
mapped).
Doing that id mapper has no reason to define
by itself
some xID to users
and groups contained into AD as they already
have some
xID.
Until now it seems to work fine...
2016-06-22 15:09 GMT+02:00
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl
I do
not see
the mapping of BUILTIN
like
others?
do you have winbind in
/etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the
following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the
following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following
URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by
utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist on
MS Windows clients, and so they can all do stuff on Sysvol and
so they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to stop
samba before replacing idmap.ldb on the additional DC's? My
script will currently watch for any idmap.ldb changes and
create a hot backup if a change is detected. It will then send
to the other DC's via rsync. I'm thinking starting and stopping
samba isn't ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap
was/is only required if you use 'winbind' that is built into the
'samba' binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list
and therefore can not be mapped during rsync. So at least these
two groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security
groups are used.
achim~

Yes I know, but each DC knows who they are and as they are members
of the 'SECURITY' domain, they aren't mapped to the DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server
(dc1) ist used for some "random group" on the target server (dc2),
the read right on sysvol for authenticated users will instead be
given to "random group". This can result in users not a member of
"random group" will not be able to access content on sysvol.
Therefore it is mandatory that these security groups are mapped to
the same gid on all dc's the sysvol conted is replicated.

This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN
in 4.2 has no impact but I assume the ACL's are read from the
security.NTACL xattr so "Authenticated Users" should always have
access because the xattr stores SID's and not the xid's. xattrs
should be replicated with rsync without any mapping required.

Did an short test if proper posix uid/gid mapping is required for
sysvol to work.
Since vfs_acl_xattr is in use samba is said to keep the posix acl's
in sync with the acl's stored in the security.NTACL xattr object.
(https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html)
If i sync from an dc with different mappings in idmap.ldb the posix
acl's seem to have precedence over the xattr values, so they can mess
up things in an way that some security groups can gain read or ever
write rights because of the different mappings.
An easy fix is adding
acl_xattr:ignore system acls = Yes
to the sysvol section in smb.conf. Posix ACL's are now ignored and
only the ACL's from the xattr are used.

if you look very closely at the differences in the 'ERROR' message,
O:LAG:DAD:PAR(
O:DAG:DAD:PAR(
The returned ACL is owned by the 'Local Admins', but it should be
owned by 'Domain Admins'. As far as I can see, windows doesn't really
care who owns an object, as long as the ACEs are correct and they are!
Secondly, more than happy to try adding a GPO, only problem is, I have
never really added one, can you point me at a good howto ?
Rowland

Sysvolcheck will always fail for me if I give my 'Domain Admins' group a
gid number other than the expected value of 3000000.

--
-James
--
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

2016-06-27 13:13:35 UTC

if you look very closely at the differences in the 'ERROR' message, you
O:LAG:DAD:PAR(
O:DAG:DAD:PAR(
The returned ACL is owned by the 'Local Admins', but it should be owned
by 'Domain Admins'. As far as I can see, windows doesn't really care who
owns an object, as long as the ACEs are correct and they are!
Secondly, more than happy to try adding a GPO, only problem is, I have
never really added one, can you point me at a good howto ?
Rowland
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Hai Rowland,

I just checked on a windows 2008 R2 server.

Sysvol security rights should be.

DOMAIN\Server Operators
Creator Owner
Authenticated Users
SYSTEM
DOMAIN\Administrators contains :
"Domain Admins",Adminstrator and "Enterprise Admins"

And the "DOMAIN\Adminstrators" is in the Buildin OU.

And same for "DOMAIN\Users" contains:
Authenticated Users, Domain Users, INTERACTIVE)

So imo this is a bug as Achim told.
Alle local security groups must map correctly.
And but must try to not mix BUILDIN\localgroup and DOMAIN\localgroup

So imo, if samba is uses as standalone server all Security groups map to BUILDIN\localgroups.

And when its a domain AD DC server.
BUILDIN maps to OU=Buildin and here are the correct groups like DOMAIN\localgroups

Greetz,

Louis

--
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

2016-06-27 13:37:12 UTC

A good howto per exampl.e

http://www.itingredients.com/how-to-disable-usb-ports-using-group-policy/

Only i did not do this as computer policy but as user policy.

In short,
1) create 2 groups:
USB-Allowed
USB-Denied

2) create 2 policies objects,
USB-Allowed
USB-Denied

And set in the allow polices
( as shown in the link but under the user polcies )

3) add correct group to the same GPO object. ( allowed with allowed , etc )

3) link the polcies objects in a OU where you can test and where the user is.

4) set the order of these policies to Allowed above the Denied.
Order 123 , is applied as 3 2 1.
1 is highest so..

This is bit like i have ...

Domain users, alle external devices are denied.
And based on group memberships :
DVD-Read
DVD-Write
USB-.. . etc etc.

And alle these are failing.
I noticed all security groups which are not "Authenticated Users" are failing.

Which is a problem for me since all my policies are group right based.

I also noticed that in my Samba 4 AD DC domain i have 4 groups in "
ForeignSecurityPrincipals (CN=ForeignSecurityPrincipals )
S-1-5-4 ( Member of : Users in CN=Buildin )
S-1-5-11 ( member of : Users and Pre-windows 2000... ) in CN=Buildin
S-1-5-17 ( member of : IIS_IUSRS ) in CN=Buildin
S-1-5-9 ( member of : Windows Authorization Access Group ) in CN=Buildin

I dont see any in ForeignSecurityPrincipals on my 2008R2

Greetz,

Louis

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

Achim Gottinger

2016-06-27 15:08:46 UTC

Post by L.P.H. van Belle
A good howto per exampl.e
http://www.itingredients.com/how-to-disable-usb-ports-using-group-policy/
Only i did not do this as computer policy but as user policy.
In short,
USB-Allowed
USB-Denied
2) create 2 policies objects,
USB-Allowed
USB-Denied
And set in the allow polices
( as shown in the link but under the user polcies )
3) add correct group to the same GPO object. ( allowed with allowed , etc )
3) link the polcies objects in a OU where you can test and where the user is.
4) set the order of these policies to Allowed above the Denied.
Order 123 , is applied as 3 2 1.
1 is highest so..
This is bit like i have ...
Domain users, alle external devices are denied.
DVD-Read
DVD-Write
USB-.. . etc etc.
And alle these are failing.
I noticed all security groups which are not "Authenticated Users" are failing.
Which is a problem for me since all my policies are group right based.
I also noticed that in my Samba 4 AD DC domain i have 4 groups in "
ForeignSecurityPrincipals (CN=ForeignSecurityPrincipals )
S-1-5-4 ( Member of : Users in CN=Buildin )
S-1-5-11 ( member of : Users and Pre-windows 2000... ) in CN=Buildin
S-1-5-17 ( member of : IIS_IUSRS ) in CN=Buildin
S-1-5-9 ( member of : Windows Authorization Access Group ) in CN=Buildin
I dont see any in ForeignSecurityPrincipals on my 2008R

Hi Louis,

I created an USB-Denied Policy and granted rights to an Domain Group
called "USB-Denied".
In the test environment i do not assign uid's and gid's and completely
rely on winbindd.

Here are the acl's. The policy applies for an normal user being a
memeber of "USB-Denied".

***@dc1:~# getfacl
/var/lib/samba/sysvol/domain.local/Policies/\{8C47B4C4-5084-43CB-BF32-999436E90283\}/
getfacl: Removing leading '/' from absolute path names
# file:
var/lib/samba/sysvol/domain.local/Policies/{8C47B4C4-5084-43CB-BF32-999436E90283}/
# owner: DOMAIN\134domain\040admins
# group: DOMAIN\134domain\040admins
user::rwx
user:3000002:rwx
user:DOMAIN\134enterprise\040admins:rwx
user:3000010:r-x
user:DOMAIN\134usb\040denied:r-x
group::rwx
group:3000002:rwx
group:DOMAIN\134enterprise\040admins:rwx
group:DOMAIN\134domain\040admins:rwx
group:3000010:r-x
group:DOMAIN\134usb\040denied:r-x
mask::rwx
other::---
default:user::rwx
default:user:3000002:rwx
default:user:DOMAIN\134enterprise\040admins:rwx
default:user:DOMAIN\134domain\040admins:rwx
default:user:3000010:r-x
default:user:DOMAIN\134usb\040denied:r-x
default:group::---
default:group:3000002:rwx
default:group:DOMAIN\134enterprise\040admins:rwx
default:group:DOMAIN\134domain\040admins:rwx
default:group:3000010:r-x
default:group:DOMAIN\134usb\040denied:r-x
default:mask::rwx
default:other::---

Replicated to dc2 with

***@dc2:~# rsync -XAavz -e ssh ***@dc1:/var/lib/samba/sysvol/
/var/lib/samba/sysvol/

These are the acl's on dc2.

***@dc2:~# getfacl
/var/lib/samba/sysvol/domain.local/Policies/\{8C47B4C4-5084-43CB-BF32-999436E90283\}/
getfacl: Removing leading '/' from absolute path names
# file:
var/lib/samba/sysvol/domain.local/Policies/{8C47B4C4-5084-43CB-BF32-999436E90283}/
# owner: domain\040admins
# group: domain\040admins
user::rwx
user:guest:rwx
user:enterprise\040admins:rwx
user:denied\040rodc\040password\040replication\040group:r-x
user:usb\040denied:r-x
group::rwx
group:guest:rwx
group:domain\040admins:rwx
group:enterprise\040admins:rwx
group:denied\040rodc\040password\040replication\040group:r-x
group:usb\040denied:r-x
mask::rwx
other::---
default:user::rwx
default:user:guest:rwx
default:user:domain\040admins:rwx
default:user:enterprise\040admins:rwx
default:user:denied\040rodc\040password\040replication\040group:r-x
default:user:usb\040denied:r-x
default:group::---
default:group:guest:rwx
default:group:domain\040admins:rwx
default:group:enterprise\040admins:rwx
default:group:denied\040rodc\040password\040replication\040group:r-x
default:group:usb\040denied:r-x
default:mask::rwx
default:other::---

In this case the gid 3000002 is mapped to the "Guest" group on dc2 and
30000010 to "denied rodc password replication group".
As an normal user i can not access sysvol on dc2 because the mapping
/var/lib/samba/sysvol/domain.local is messed up (no Authenticated Users
ACL).

***@dc2:~# getfacl /var/lib/samba/sysvol
getfacl: Removing leading '/' from absolute path names
# file: var/lib/samba/sysvol
# owner: root
# group: BUILTIN\134administrators
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:guest:rwx
group:domain\040guests:r-x
group:BUILTIN\134server\040operators:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:guest:rwx
default:group:domain\040guests:r-x
default:group:BUILTIN\134server\040operators:r-x
default:mask::rwx
default:other::---

achim~

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

Achim Gottinger

2016-06-27 12:30:18 UTC

Post by Achim Gottinger
Created an feature request
"add resolving for well known security principals"
https://bugzilla.samba.org/show_bug.cgi?id=11997

2016-06-22 16:37 GMT+02:00 L.P.H. van Belle
@Mathias,
Pretty strange then, running some years like this without
any problem.
Yes we had few problems with "rights" in sysvol, but i
fixed this all
outside linux, and with that i mean. Changed rights from
within windows or
added registry changes or patches, or a local clean up of
the policies.
At the install of my DC2 i also synced the idmap.ldb, and
then a
net idmap flush on both servers to make my both dc's in sync.
And i keep it in sync with my rsync/unison setup.
All new added, but i'll keep an eye also in this and i'll
recheck my logs.
But i dont think i'll find anything here.
I'll keep notice on your "workaround".
Which backend are you using matias?
Mine : (idmap config NTDOMAIN : backend = ad)
Gr.
Louis
OK you keep idmap.ldb synched, that's what I missed until few
days and was
the reason that is was not working.
Our choice to give each and users and groups into AD some xID
is only to
avoid usage of mapping. I expect the synchronization of
idmap.ldb (if done
often enough) would be sufficient. But I don't always like
magic : )
Thank you for precisions !
Cheers all
-----Oorspronkelijk bericht-----
dufresne
Verzonden: woensdag 22 juni 2016 15:31
CC: samba
Onderwerp: Re: [Samba] Rights issue on GPO
@LPH van Belle
I did tried (and still use) "acl_xattr:ignore system
acls = yes" as shown
on the first mail of that thread. And even using that
rights errors on
GPO
files _are_ an issue. Otherwise that thread won't have
been opened of
course : )
Regarding how we decided to workaround almost
definitively with that was
to
give every users and groups in AD some xID, also those
in CN=Builtin and
CN=Users. We also cleaned our idmap.ldb to keep inside
only special users
/
groups (as "local system" / S-1-5-18, "guests" /
S-1-5-32-546...).
We also add some rsync to keep idmap.ldb synchronized
on all our DC, for
these special items have same mapped xID in case they
are used (and so
mapped).
Doing that id mapper has no reason to define by itself
some xID to users
and groups contained into AD as they already have some
xID.
Until now it seems to work fine...
2016-06-22 15:09 GMT+02:00
On 06/22/2016 02:44 PM,
Why is is when I do a getfacl I do not see
the mapping of BUILTIN
like
others?
do you have winbind in
/etc/nsswitch.conf?
mj
I also thought winbind was only necessary on
member servers.
--
-James
--
To unsubscribe from this list go to the following
URL and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL
and read the
https://lists.samba.org/mailman/options/samba
--
To unsubscribe from this list go to the following URL and
read the
https://lists.samba.org/mailman/options/samba
If I assign every user a UID and select groups a GID by utilizing
rfc2307 on my DC's. Would I still benefit from keeping idmap.ldb
synchronized? I'm thinking XID's are obsolete at that point?
Only users and groups in AD will avoid id mapper by that
workaround. But there are others accounts ("local system",
"guest", "local administrator"...) all these accounts exist
on MS Windows clients, and so they can all do stuff on Sysvol
and so they can all go through id mapper.
So no. There no way (for me at least :) to totally avoid id
mapper and so you should keep idmap.ldb synched.
-- -James
-- To unsubscribe from this list go to the following
URL and read the
instructions: https://lists.samba.org/mailman/options/samba

I'm in the process now of creating a script to sync idmap.ldb.
Does anyone have one at the moment? Is it best practice to
stop samba before replacing idmap.ldb on the additional DC's?
My script will currently watch for any idmap.ldb changes and
create a hot backup if a change is detected. It will then send
to the other DC's via rsync. I'm thinking starting and
stopping samba isn't ideal during production hours.

If you are running Samba >= 4.2.0 with the separate 'winbindd'
binary, there is no reason to sync idmap.ldb. Syncing idmap
was/is only required if you use 'winbind' that is built into
the 'samba' binary.
Rowland

Hello Rowland,
If you take an look on your sysvol rights there are two still
unresoved groups SECURITY\Local System and SECURITY\Autheticated
Users. These show up with gid's from idmap.ldb in the acl list
and therefore can not be mapped during rsync. So at least these
two groups need idntical mapping on all dc's. It is however not
neccessary to keep idmap in sync as long as no ther security
groups are used.
achim~

Yes I know, but each DC knows who they are and as they are
members of the 'SECURITY' domain, they aren't mapped to the
DOMAIN or BUILTIN.
Rowland

If the gid used for "Authenticated Users" on the source server
(dc1) ist used for some "random group" on the target server (dc2),
the read right on sysvol for authenticated users will instead be
given to "random group". This can result in users not a member of
"random group" will not be able to access content on sysvol.
Therefore it is mandatory that these security groups are mapped to
the same gid on all dc's the sysvol conted is replicated.

This was an issue i ran into back on samba 4.0/4.1. Mapping BUILTIN
in 4.2 has no impact but I assume the ACL's are read from the
security.NTACL xattr so "Authenticated Users" should always have
access because the xattr stores SID's and not the xid's. xattrs
should be replicated with rsync without any mapping required.

Did an short test if proper posix uid/gid mapping is required for
sysvol to work.
Since vfs_acl_xattr is in use samba is said to keep the posix acl's
in sync with the acl's stored in the security.NTACL xattr object.
(https://www.samba.org/samba/docs/man/manpages/vfs_acl_xattr.8.html)
If i sync from an dc with different mappings in idmap.ldb the posix
acl's seem to have precedence over the xattr values, so they can
mess up things in an way that some security groups can gain read or
ever write rights because of the different mappings.
An easy fix is adding
acl_xattr:ignore system acls = Yes
to the sysvol section in smb.conf. Posix ACL's are now ignored and
only the ACL's from the xattr are used.

OK, I finally got round to installing win10 in a VM on my new
computer, so I have been able to fully test 'sysvol' on both DCs.
getfacl: Removing leading '/' from absolute path names
# file: usr/local/samba/var/locks/sysvol/
# owner: root
# group: BUILTIN\134administrators
# flags: -s-
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:BUILTIN\134server\040operators:r-x
group:3000002:rwx
group:3000003:r-x
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:BUILTIN\134server\040operators:r-x
default:group:3000002:rwx
default:group:3000003:r-x
default:mask::rwx
default:other::---
getfacl: Removing leading '/' from absolute path names
# file: usr/local/samba/var/locks/sysvol/
# owner: root
# group: BUILTIN\134administrators
# flags: -s-
user::rwx
user:root:rwx
user:BUILTIN\134administrators:rwx
user:BUILTIN\134server\040operators:r-x
user:3000014:r-x
user:3000030:rwx
group::rwx
group:BUILTIN\134administrators:rwx
group:BUILTIN\134server\040operators:r-x
group:3000014:r-x
group:3000030:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:BUILTIN\134administrators:rwx
default:user:BUILTIN\134server\040operators:r-x
default:user:3000014:r-x
default:user:3000030:rwx
default:group::---
default:group:BUILTIN\134administrators:rwx
default:group:BUILTIN\134server\040operators:r-x
default:group:3000014:r-x
default:group:3000030:rwx
default:mask::rwx
default:other::---
group:3000002:rwx
group:3000003:r-x
The first is for the SID 'CN=S-1-5-18' , this is 'Local System', the
second is for the SID 'CN=S-1-5-11', this is 'Authenticated Users'
group:3000014:r-x
group:3000030:rwx
The first is for the SID 'CN=S-1-5-11' this is 'Authenticated Users',
the second is for the SID 'CN=S-1-5-18' , this is 'Local System'
Administrators
Server Operators
Local System
Authenticated Users
Administrators
Server Operators
Authenticated Users
Local System
So, from the Unix point of view, 'sysvol' belongs to the correct
users/groups, but what about windows ?
If I navigate to each DC on win10, select the 'sysvol' share and
Authenticated Users
SYSTEM
Administrators
Server Operators
The same as on the DCs.
I do not 'sync' idmap.ldb and the DCs are both running 4.4.3
Bearing in mind the above, why are people still syncing 'idmap.ldb' if
they are using the separate 'winbindd' binary ??
The only slight 'problem' that I can see, getfacl seems to return
different results depending on which DC it is run on, the same basic
result, but on one it is a user and on the other it is a group.
Rowland

Thank you for the test. Do you run samba-tool ntacl sysvolreset after
rsync on dc2? What command are you using to synchronize the sysvol folders?
I tried it on debian jessie with debian an sernet samba 4.2 and
backported 4.3. Synchronisation happend with rsync/ssh and no
sysvolreset was run here. There is no way rsync can map the different
gid's for groups and users whom do not resolve to names.
If i run sysvolreset after rsync propper mappings are restored on dc2
and the folders can be accessed from windows.

achim~

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

Achim Gottinger

2016-06-29 15:01:24 UTC

Did you have an chance to look at your method for replication yet Rowland?

Post by Achim Gottinger
Thank you for the test. Do you run samba-tool ntacl sysvolreset after
rsync on dc2?

This may be where the problems come in, let me look into this and
report back
Rowland

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

mathias dufresne

2016-06-30 10:00:20 UTC

Sorry to ask that but this thread is quite long and that makes
understanding difficult, at least to me. What is the status of all that? I
believe at one moment it was writtent using winbindd is solution, that with
winbindd instead of winbind we don't need to synchronize idmap.ldb to get
GPOs working well even with numerous DCs.

Please do answer by "yes" or "no". If you reply, any of you, I'd like a
clear résumé of all that. I understand that request would need time to be
written, more than answering yes or no, and I would understand if no one
wants to take that time.

Post by Achim Gottinger
Did you have an chance to look at your method for replication yet Rowland?

Post by Achim Gottinger
Thank you for the test. Do you run samba-tool ntacl sysvolreset after

Post by Achim Gottinger
rsync on dc2?

This may be where the problems come in, let me look into this and report
back
Rowland

No, been updating my patches to change 'provision' and I am working on
Stefan's sysvol patches at the moment.
Rowland
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

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

Achim Gottinger

2016-06-30 10:33:42 UTC

Post by mathias dufresne
Sorry to ask that but this thread is quite long and that makes
understanding difficult, at least to me. What is the status of all that? I
believe at one moment it was writtent using winbindd is solution, that with
winbindd instead of winbind we don't need to synchronize idmap.ldb to get
GPOs working well even with numerous DCs.
Please do answer by "yes" or "no". If you reply, any of you, I'd like a
clear résumé of all that. I understand that request would need time to be
written, more than answering yes or no, and I would understand if no one
wants to take that time.

Hello Matthias,

With the switch from winbind to winbindd libnss-winbind is able to
resolve BUILTIN groups/users to proper names and not just gid's.
For the sysvol folder beside BUILTIN groups also "Well known security
principal groups" are used, these do not resolve to names and no gid's
uid's can be assigned to them unlike normal domain groups.
There is also an problem with the rsync method described in the samba
wiki, user and group mapping does not work at all. Even for normal
groups in /etc/group with different gid's on different servers. Rsync
always simply copies the gid's (uid's). An workaroud is to use rsync via
ssh (rsync -XAavz -e ssh ***@dc1:/var/lib/samba/sysvol/
/var/lib/samba/sysvol/).
But for the sysvol share this will only map the builtin groups correct.
For gpo's the access rights are stored in the active directory tree
using the groups sid's. If you run "samba-tool ntacl sysvolreset" on the
server you synced sysvol to, the rights stored in the ad tree are
applied to the sysvol share's posix acl's with help of the local
idmap.ldb so this will assign the correct acl's for the "Well known
security principal groups" as well because the sid->gid/uid mappings
stored in the local idmap.ldb are now used. This does also work if
winbind is/was used instead of winbindd.
To get rid of eighter syncing idmap.ldb or running "samba-tool ntacl
sysvolreset" on each dc after rsync, the "Well known security principal
groups" must resolve to names like the BUILTIN groups. I filed an
enhancement request for that
https://bugzilla.samba.org/show_bug.cgi?id=11997.

Hope that clarifies things,
achim~

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

mathias dufresne

2016-06-30 13:02:44 UTC

Hi Achim,

Thank you, yes that clarifies things.

So until the feature to get user names resolved also for security account
(local system, authenticated users, everyone... those described here:
https://support.microsoft.com/en-us/kb/243330) there is no way to be sure
rights are the same on all DC except to synchronize idmap.ldb. Clear enough
: )

With the switch from winbind to winbindd libnss-winbind is able to resolve
BUILTIN groups/users to proper names and not just gid's.
For the sysvol folder beside BUILTIN groups also "Well known security
principal groups" are used, these do not resolve to names and no gid's
uid's can be assigned to them unlike normal domain groups.
There is also an problem with the rsync method described in the samba
wiki, user and group mapping does not work at all. Even for normal groups
in /etc/group with different gid's on different servers. Rsync always
simply copies the gid's (uid's). An workaroud is to use rsync via ssh
/var/lib/samba/sysvol/).
But for the sysvol share this will only map the builtin groups correct.
For gpo's the access rights are stored in the active directory tree using
the groups sid's. If you run "samba-tool ntacl sysvolreset" on the server
you synced sysvol to, the rights stored in the ad tree are applied to the
sysvol share's posix acl's with help of the local idmap.ldb so this will
assign the correct acl's for the "Well known security principal groups" as
well because the sid->gid/uid mappings stored in the local idmap.ldb are
now used. This does also work if winbind is/was used instead of winbindd.
To get rid of eighter syncing idmap.ldb or running "samba-tool ntacl
sysvolreset" on each dc after rsync, the "Well known security principal
groups" must resolve to names like the BUILTIN groups. I filed an
enhancement request for that
https://bugzilla.samba.org/show_bug.cgi?id=11997.
Hope that clarifies things,
achim~
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

--
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

2016-06-27 13:04:12 UTC