Re: [Patch] Add support for Windows BUILTIN groups

[Davy Defaud <davy.defaud [at] free.fr>]

Le 30/01/2014 19:56, Arthur de Jong a écrit :
> On Thu, 2014-01-30 at 17:04 +0100, Davy Defaud wrote:
>> Here's a very quick and simple patch in order to get Windows BUILTIN
>> groups when searching a group by gid (RID).
> Thanks for the patch. I don't have access to an AD instance to test this
> but the patch seems simple enough.
>

You're welcome. Thank *you* for all your so valuable work!...

>> The aim of this patch is to map the gid (gidNumber) to an AD SID RID
>> between 544 and 552, because in that case the SID prefix is not the
>> domain's prefix (S-1-5-21-dddddddddd-ddddddddd-ddddddddd) but the
>> BUILTIN SID prefix (1-5-32).
> Is it correct that there normally should not be any domain groups in AD
> that have a RID in the range 544 to 522?

http://pig.made-it.com/uidgid.html
http://support.microsoft.com/kb/243330

Here's a table to summarize the document from M$:
___________________________________________________________
|RID min|RID max|SID prefix       | Name
-----------------------------------------------------------
| 500   | 502   | S-1-5-21-domain | Special domain accounts
-----------------------------------------------------------
| 512   | 520   | S-1-5-21-domain | Special domain groups
-----------------------------------------------------------
| 521   | 521   | S-1-5-21-domain | Read-only Domain Controllers
-----------------------------------------------------------
| 522   | 522   | S-1-5-21-domain | Cloneable Domain Controllers (3)
-----------------------------------------------------------
| 544   | 552   | S-1-5-32        | built-in groups
-----------------------------------------------------------
| 553   | 553   | S-1-5-21-domain | Special domain group
-----------------------------------------------------------
| 554   | 562   | S-1-5-32        | additional built-in
groups (1)
-----------------------------------------------------------
| 569   | 569   | S-1-5-32        | Cryptographic Operators (2)
-----------------------------------------------------------
| 571   | 572   | S-1-5-21-domain | Denied RODC Password Replication
Group (2)
-----------------------------------------------------------
| 573   | 574   | S-1-5-32        | additional built-in
groups (2)
-----------------------------------------------------------
| 575   | 580   | S-1-5-32        | additional built-in groups (3)
------------------------------------------------------------

(1) « The following groups appear as SIDs until a Windows Server 2003
domain controller is made the primary domain controller (PDC) operations
master role holder. »
(2) « The following groups appear as SIDs until a Windows Server 2008 or
Windows Server 2008 R2 domain controller is made the primary domain
controller (PDC) operations master role holder. »
(3) « The following groups appear as SIDs until a Windows Server 2012
domain controller is made the primary domain controller (PDC) operations
master role holder. »


As you can see, there are two other ranges plus an isolated group (579)
that are prefixed by S-1-5-32. So my patch should concern the following
RIDs: 544-552, 554-562, 569, 573-580. But, perhaps a safer, simpler and
compatible way to do the work could be to search in S-1-5-21-domain
first and then, if nothing is found, in S-1-5-32 (only for RIDs between
500 and 999, of course). WDYT?

>
>> For example, if you add a user to the Administrators builtin group
>> (S-1-5-21-544), now you should be able to get this group through nslcd,
>> instead of having this error message:
> That should probably be S-1-5-32-544 if I understand correctly.

Of course, my bad! :-(

>
>> $ groups myuser
>> myuser : Domain Users groups: cannot find name for group ID 544
>> 544 compta pantin
>>
>> Of course, this could be made in a more configurable way...
> If this range is never used for domain groups I don't see a strong need
> for configurability unless there are other ranges that may also need to
> be mapped to other SIDs.

The RIDs are supposed to be unique, whatever their SID prefixes are.
But we could give priority to domain groups, if we choose the
proposition above...

>
> There was a memory leak in your patch though: sid2search() returns a
> freshly allocated string every time but I've fixed that.

Well, my C skills are rather scholar. Sorry for the mistake.

> I'll push the
> change via Git if you can confirm that the ranges shouldn't clash.
>
> Thanks!
>

Cool! Thank you for including this functionality. :-)

Cheers,

Davy


-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users/