samba - Sep 2017 - BUILTIN\Administrators - failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND

Thank you very much for clarifying the ID mapping "magic";)
 
> You do not need 'posixgroup', it is an auxiliary objectclass of
group, you can add any of the rfc2307 attributes without it.
Well, is there any option to remove it? Because "posixgroup" is on
every group that was migrated from Samba 3.
And I cannot edit this attribute in ADUC (delete button is grayed).
> Try restarting Samba and then run 'getent group Domain\ Admins'
getent group Domain\ Admins
COMPANY\domain admins:x:512:

Which is expected, because it has set NIS domain and GID in ADUC. But
when I look to sysvol, I don't see Domain admins but
BUILTIN\Administrators (Domain Admins are members of this group). So I
am confused by behavior of BUILTIN groups.
I made some investigations about BUILTIN\Administrators.

Production domain (migrated from Samba 3):
wbinfo --sid-to-uid=S-1-5-32-544
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-32-544 to uid

ldbsearch -H /var/lib/samba/private/idmap.ldb | grep S-1-5-32-544 -A2
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_GID
xidNumber: 15538
distinguishedName: CN=S-1-5-32-544

Testing lab domain (provisioned from scratch):
wbinfo --sid-to-uid=S-1-5-32-544
3000003

ldbsearch -H /usr/local/samba/private/idmap.ldb | grep S-1-5-32-544
-A2
dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_BOTH
xidNumber: 3000003
distinguishedName: CN=S-1-5-32-544

Almost every (except 0, 99 and 100) BUILTIN xidNumber on my migrated
domain starts with 15000. On provisioned domain it starts with 3000000.
Is that the way to fix my errors? Correct idmap.ldb to match cleanly
provisioned Samba AD? Is save to edit this file?


Jiří

On Tue, 05 Sep 2017 12:22:47 +0200
Jiří Černý via samba <samba at lists.samba.org> wrote:
>> To Rowland:
>>> This was perfectly common, nobody thought this would ever be a
>>> problem,mainly because you had to have a user or group
>>> in /etc/passwd>
>>> or /etc/group mapped to a Samba. Now with AD, you do not need a
user
>>> or group in /etc/passwd or /etc/group, so any user or group that
uses
>>> the RID as a Unix ID is> probably too low and is denying the use
of
>>> any local Unix users
>> Yes, but where is main problem/failure? We had working Samba 3
domain
>> with LDAP backend. Made by documentation. We migrated to Samba 4
AD,
>> of course with assistance of documentation/wiki.
>> So there was no failure in process of migration, but it lead to ID
>> mapping mess which I can't fix.
>The problem lies way back when the domain was set up. As I said,
>everybody thought that using the RID as a Unix ID was an acceptable
>thing to do. Hindsight has proven this wasn't such a good idea, a lot
>of the RIDs are in the 500 range (including Domain Users). This means
>that if you use the winbind 'ad' backend, you need to set the lower
>Domain range to '500' to get any of your users known to Unix, this
>means you cannot have ANY local Unix users.
>> 
>>> I hope you are not thinking of using GPOs, 'Domain Admins'
needs
to
>>> own things is 'sysvol' and cannot if they are a group (the
gidNumber
>>> makes them a group)
>> Of course I am thinking of using GPOs. Windows
>>are ok with it, because it uses SIDs. I have problems only in linux,
>> because bad ID mapping, respectively samba-tool ntacl sysvolcheck,
>> because it's expecting diferent ID numbers as I have. 
>> Domain Admins is group. Only deference is that in our (migrated)
>> domain id has objectClass top; posixgroup; group and in cleanly
>> provisioned AD it has only top; group.
>You do not need 'posixgroup', it is an auxiliary objectclass of
group,
>you can add any of the rfc2307 attributes without it.
> But in both cases I see group. So I have to apologize, because I
> probably don't understand you.
> So if I set GID, then ID mapping in linux makes that as group, but
if
> it's not set, than Samba makes some "magic" and give Domain
Admins
ID
> as this "goup" act as user?
>It isn't really magic, idmap on a DC works two ways, the first is
when
>a user or group first contacts the DC, it is given an xidNumber, this
>is stored in idmap.ldb on the DC, it also set to a 'type'. This can
be
>'ID_TYPE_UID', 'ID_TYPE_GID' or 'ID_TYPE_BOTH', the
later means that
a
>group is also a user. The second way is if you give a user a
uidNumber
>or give a group a gidNumber, this turns off what is in idmap.ldb and
>makes the user or group become just a user or group, in the case of
>Domain Admins, this stops the group owning anything in 'sysvol'
>> > If you can change the Unix IDs, then this is the way to goNot
>> > problem
>> there in linux side or AUDC to change it. But it doesn't like it
will
>> help me. Now, I have all BUILTIN groups without GID, cache flushed
but
>> now luck. Even if I removed all bad GIDs and checked possible
>> collision with UNIX groups. Samba doesn't give me IDs like 30000,
bud
>> something different. Look at my sysvol:
>> getfacl /var/lib/samba/sysvol/
>> getfacl: Removing leading '/' from absolute path names
>> # file: var/lib/samba/sysvol/
>> # owner: 1037
>> # group: 544
>> user::rwx
>> user:10037:rwx
>> user:15543:r-x
>> user:15544:rwx
>> user:15554:r-x
>> group::rwx
>> group:544:rwx
>> group:BUILTIN\134server\040operators:r-x
>> group:15544:rwx
>> group:15554:r-x
>> mask::rwx
>> other::---
>> default:user::rwx
>> default:user:1037:rwx
>> default:user:15543:r-x
>> default:user:15544:rwx
>> default:user:15554:r-x
>> default:group::---
>> default:group:544:rwx
>> default:group:BUILTIN\134server\040operators:r-x
>> default:group:15544:rwx
>> default:group:15554:r-x
>> default:mask::rwx
>> default:other::---As you can see, there is something with 15000 +
RID
>> pattern. Definitely from old LDAP backend. 544 are
>> BUILTIN\Administrators, 1037 is old UID of COMPANY\Administrator.
Even
>> if I deleted GIDs and flushed cache it doesn't work:
>> wbinfo -i Administrator
>>
COMPANY\administrator:*:0:513::/home/COMPANY/administrator:/bin/false
>> I am afraid that our domain is bad provisioned (upgraded) from
>> beginning. Is there any tool/advance, how to manually fix/change
IDs
>> in Samba AD? And some kind of list of ID which Samba AD uses in
it's
>> "ID magic"?
>> I believe that can be fixed by setting the "right" numbers.
>> Thank you for you help. I really appreciate it.Jiří
>> 
Try restarting Sambaand then run 'getent group Domain\ Admins'

Rowland

On Tue, 05 Sep 2017 14:01:37 +0200
Jiří Černý via samba <samba at lists.samba.org> wrote:
> Thank you very much for clarifying the ID mapping "magic";)
>  
>> You do not need 'posixgroup', it is an auxiliary objectclass of
>> group, you can add any of the rfc2307 attributes without it.
> Well, is there any option to remove it? Because "posixgroup" is
on
> every group that was migrated from Samba 3.
> And I cannot edit this attribute in ADUC (delete button is grayed).
It is probably 'greyed' out because no Windows tools use it or will add
it. You will probably need to use Unix tools (ldb or ldap) to remove
them, but you can if you so wish ignore them. What you should never do
is to rely on them being there, because they may or may not be there.
> 
> > Try restarting Samba and then run 'getent group Domain\
Admins'
> getent group Domain\ Admins
> COMPANY\domain admins:x:512:
> 
> Which is expected, because it has set NIS domain and GID in ADUC.
You need to remove the gidNumber from Domain Admins. If you add any
GPOs to 'sysvol' (other than the two default ones), they will be
created in 'sysvol\DOMAIN.LOCAL\Policies\{GUID}'
And the Sddl will be:

O:DAG:DAD:PAI(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;ED)(A;OICI;0x1200a9;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;DA)(A;OICI;FA;;;S-1-5-21-2695348288-4157658249-429813502-519)

The important bit (as far as the Unix OS is concerned) is 'O:DAG:DA',
which if we expand it becomes 'O:DA G:DA' 
O = Owner
G = Group
DA = Domain Admins

So we can see that Domain Admins is both the owner and group of the
directory. If Domain Admins has a gidNumber it is just a group and
'O:DAG:DA' becomes 'O:??G:DA'

> But
> when I look to sysvol, I don't see Domain admins but
> BUILTIN\Administrators (Domain Admins are members of this group). So I
> am confused by behavior of BUILTIN groups.
> I made some investigations about BUILTIN\Administrators.
> 
> Production domain (migrated from Samba 3):
> wbinfo --sid-to-uid=S-1-5-32-544
> failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-32-544 to uid
> 
> ldbsearch -H /var/lib/samba/private/idmap.ldb | grep S-1-5-32-544 -A2
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_GID
> xidNumber: 15538
> distinguishedName: CN=S-1-5-32-544
and mine is:

dn: CN=S-1-5-32-544
cn: S-1-5-32-544
objectClass: sidMap
objectSid: S-1-5-32-544
type: ID_TYPE_BOTH
xidNumber: 3000000
distinguishedName: CN=S-1-5-32-544

> 
> Testing lab domain (provisioned from scratch):
> wbinfo --sid-to-uid=S-1-5-32-544
> 3000003
> 
> ldbsearch -H /usr/local/samba/private/idmap.ldb | grep S-1-5-32-544
> -A2
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_BOTH
> xidNumber: 3000003
> distinguishedName: CN=S-1-5-32-544
> 
> Almost every (except 0, 99 and 100) BUILTIN xidNumber on my migrated
> domain starts with 15000. On provisioned domain it starts with
> 3000000. Is that the way to fix my errors? Correct idmap.ldb to match
> cleanly provisioned Samba AD? Is save to edit this file?
> 
> 
It is perfectly safe to edit, in fact if you add another DC, you have
to edit it on the second DC by overwriting it with the idmap.ldb from
the first.

Let me have a look at the classicupgrade code and get back to you, it
shouldn't create xidNumbers like that. Speaking of which, can you check
in idmap.ldb for the DN 'dn: CN=CONFIG'. What are 'lowerBound'
and
'upperBound' set to ?

Rowland

Rowland, 

Are (one) these not an option for him to correct this? 

      --allocate-uid                                 Get a new UID out of idmap
      --allocate-gid                                 Get a new GID out of idmap
      --set-uid-mapping=UID,SID                      Create or modify uid to sid
mapping in idmap
      --set-gid-mapping=GID,SID                      Create or modify gid to sid
mapping in idmap
      --remove-uid-mapping=UID,SID                   Remove uid to sid mapping
in idmap
      --remove-gid-mapping=GID,SID                   Remove gid to sid mapping
in idmap
      --sids-to-unix-ids=Sid-List                    Translate SIDs to Unix IDs
      --unix-ids-to-sids=ID-List (u<num> g<num>)     Translate Unix
IDs to SIDs


Greetz, 

Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens 
> Rowland Penny via samba
> Verzonden: dinsdag 5 september 2017 14:42
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] BUILTIN\Administrators - failed to 
> call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> 
> On Tue, 05 Sep 2017 14:01:37 +0200
> Ji??í ??erný via samba <samba at lists.samba.org> wrote:
> 
> > Thank you very much for clarifying the ID mapping "magic";)
> >  
> >> You do not need 'posixgroup', it is an auxiliary
objectclass of
> >> group, you can add any of the rfc2307 attributes without it.
> 
> > Well, is there any option to remove it? Because "posixgroup"
is on
> > every group that was migrated from Samba 3.
> > And I cannot edit this attribute in ADUC (delete button is grayed).
> 
> It is probably 'greyed' out because no Windows tools use it 
> or will add it. You will probably need to use Unix tools (ldb 
> or ldap) to remove them, but you can if you so wish ignore 
> them. What you should never do is to rely on them being 
> there, because they may or may not be there.
> 
> > 
> > > Try restarting Samba and then run 'getent group Domain\
Admins'
> > getent group Domain\ Admins
> > COMPANY\domain admins:x:512:
> > 
> > Which is expected, because it has set NIS domain and GID in ADUC.
> 
> You need to remove the gidNumber from Domain Admins. If you 
> add any GPOs to 'sysvol' (other than the two default ones), 
> they will be created in 'sysvol\DOMAIN.LOCAL\Policies\{GUID}'
> And the Sddl will be:
> 
> O:DAG:DAD:PAI(A;OICIIO;FA;;;CO)(A;OICI;0x1200a9;;;ED)(A;OICI;0
> x1200a9;;;AU)(A;OICI;FA;;;SY)(A;OICI;FA;;;DA)(A;OICI;FA;;;S-1-
> 5-21-2695348288-4157658249-429813502-519)
> 
> The important bit (as far as the Unix OS is concerned) is 
> 'O:DAG:DA', which if we expand it becomes 'O:DA G:DA' 
> O = Owner
> G = Group
> DA = Domain Admins
> 
> So we can see that Domain Admins is both the owner and group 
> of the directory. If Domain Admins has a gidNumber it is just 
> a group and 'O:DAG:DA' becomes 'O:??G:DA'
> 
> 
> > But
> > when I look to sysvol, I don't see Domain admins but 
> > BUILTIN\Administrators (Domain Admins are members of this 
> group). So I 
> > am confused by behavior of BUILTIN groups.
> > I made some investigations about BUILTIN\Administrators.
> > 
> > Production domain (migrated from Samba 3):
> > wbinfo --sid-to-uid=S-1-5-32-544
> > failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND Could 
> not convert 
> > sid S-1-5-32-544 to uid
> > 
> > ldbsearch -H /var/lib/samba/private/idmap.ldb | grep 
> S-1-5-32-544 -A2
> > dn: CN=S-1-5-32-544
> > cn: S-1-5-32-544
> > objectClass: sidMap
> > objectSid: S-1-5-32-544
> > type: ID_TYPE_GID
> > xidNumber: 15538
> > distinguishedName: CN=S-1-5-32-544
> 
> and mine is:
> 
> dn: CN=S-1-5-32-544
> cn: S-1-5-32-544
> objectClass: sidMap
> objectSid: S-1-5-32-544
> type: ID_TYPE_BOTH
> xidNumber: 3000000
> distinguishedName: CN=S-1-5-32-544
> 
> 
> > 
> > Testing lab domain (provisioned from scratch):
> > wbinfo --sid-to-uid=S-1-5-32-544
> > 3000003
> > 
> > ldbsearch -H /usr/local/samba/private/idmap.ldb | grep S-1-5-32-544
> > -A2
> > dn: CN=S-1-5-32-544
> > cn: S-1-5-32-544
> > objectClass: sidMap
> > objectSid: S-1-5-32-544
> > type: ID_TYPE_BOTH
> > xidNumber: 3000003
> > distinguishedName: CN=S-1-5-32-544
> > 
> > Almost every (except 0, 99 and 100) BUILTIN xidNumber on my 
> migrated 
> > domain starts with 15000. On provisioned domain it starts with 
> > 3000000. Is that the way to fix my errors? Correct 
> idmap.ldb to match 
> > cleanly provisioned Samba AD? Is save to edit this file?
> > 
> > 
> 
> It is perfectly safe to edit, in fact if you add another DC, 
> you have to edit it on the second DC by overwriting it with 
> the idmap.ldb from the first.
> 
> Let me have a look at the classicupgrade code and get back to 
> you, it shouldn't create xidNumbers like that. Speaking of 
> which, can you check in idmap.ldb for the DN 'dn: CN=CONFIG'. 
> What are 'lowerBound' and 'upperBound' set to ?
> 
> Rowland
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

On Tue, 5 Sep 2017 14:45:02 +0200
L.P.H. van Belle <belle at bazuin.nl> wrote:
> Rowland, 
> 
> Are (one) these not an option for him to correct this? 
> 
>       --allocate-uid                                 Get a new UID
> out of idmap --allocate-gid                                 Get a new
> GID out of idmap --set-uid-mapping=UID,SID
> Create or modify uid to sid mapping in idmap
> --set-gid-mapping=GID,SID                      Create or modify gid
> to sid mapping in idmap
> --remove-uid-mapping=UID,SID                   Remove uid to sid
> mapping in idmap --remove-gid-mapping=GID,SID
> Remove gid to sid mapping in idmap
> --sids-to-unix-ids=Sid-List                    Translate SIDs to Unix
> IDs --unix-ids-to-sids=ID-List (u<num> g<num>)     Translate
Unix IDs
> to SIDs 
> 
Don't think so, the problem seems to be that somebody thought it would
be a good idea to mess with idmap.ldb during the classicupgrade.

This from upgrade.py:

    logger.info("Adding groups")
    try:
        # Export groups to samba4 backend
        logger.info("Importing groups")
        for g in grouplist:
            # Ignore uninitialized groups (gid = -1)
            if g.gid != -1:
                add_group_from_mapping_entry(result.samdb, g, logger)
                add_ad_posix_idmap_entry(result.samdb, g.sid, g.gid,
"ID_TYPE_GID", logger)
                add_posix_attrs(samdb=result.samdb, sid=g.sid,
                name=g.nt_name, nisdomain=domainname.lower(),
                xid_type="ID_TYPE_GID", logger=logger)

There is a similar one for users.

I am beginning to think that it is a BAD idea to upgrade from a PDC to
an AD DC, you would probably be better off creating a new AD domain and
exporting the users & groups to it, that way you can ensure it works as
expected.

Rowland