On 04/07/14 11:06 +0530, Sankar P wrote: ldapsearch -Y DIGEST-MD5 -U joe -H ldap://192.0.2.1 \ -b "dc=example,dc=com" -s "sub" "objectSid=XXX" dn -- Dan White

2014-04-07 21:48 GMT+05:30 Mark Pröhl <mark(a)mproehl.net&gt;: I tried to do this using the C openldap binding and when having "objectSid" as the filter, I get the full DN of the group but not its members. If I just use "sid" I get nothing. The count of the results returned is zero. My source code is: http://paste.opensuse.org/74038351 Can you help with it ? What do I miss ? Thanks. -- Sankar P http://psankar.blogspot.com

oh okay. Thanks for your explanation. I changed my code to: struct timeval timeout = {10,0}; char *attr_list[] = {"member", NULL}; LDAPMessage *searchresult = NULL; gch = get_gch_from_queue(); sts = ldap_search_ext_s(gch->ld, "<sid=S-...>", LDAP_SCOPE_BASE, "(objectClass=*)", attr_list, 0, NULL, NULL, &timeout, LDAP_NO_LIMIT, &searchresult); and this returns a status of LDAP_UNWILLING_TO_PERFORM What am I doing wrong ? -- Sankar P http://psankar.blogspot.com

When retrieving large group memberships from AD you must use Microsoft's implementation of ranging. When the group membership exceeds the limit established in the domain controller (usually 1500 users) AD returns an empty result set in the member attribute and then adds a new attribute containing a partial result set. You must then submit multiple subsequent searches renaming this new attribute each time to retrieve the remainder of the result set. You can google on AD and ranging for more details. There are ways to disable this in AD as well but most AD administrators will refuse to do it. -Jon C. Kidder American Electric Power Middleware Services Email: jckidder(a)aep.com Phone: 614-716-4970 -----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Sankar P Sent: Friday, April 11, 2014 2:08 AM To: Mark Pröhl Cc: openldap-technical(a)openldap.org Subject: Re: Getting the list of members in an AD group This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. ********************************************************************** The group whose SID that I am trying to take is the default "Domain Users" group. The ldapsearch query too fails for that but for any other custom groups, the membership information is printed. So is there a different style that we should follow for getting the "Domain Users" group members ? 2014-04-10 16:20 GMT+05:30 Sankar P <sankar.curiosity(a)gmail.com&gt;: -- Sankar P http://psankar.blogspot.com

http://msdn.microsoft.com/en-us/library/aa367017(v=vs.85).aspx I personally use the LSC project to replicate AD with OpenLDAP and have published a relevant snippet of JavaScript that does this for large user groups. http://lists.lsc-project.org/pipermail/lsc-users/2013-September/001606.html -Jon C. Kidder American Electric Power Middleware Services Email: jckidder(a)aep.com Phone: 614-716-4970 -----Original Message----- From: Sankar P [mailto:sankar.curiosity@gmail.com] Sent: Friday, May 02, 2014 1:09 AM To: Jon C Kidder Cc: Mark Pröhl; openldap-technical(a)openldap.org Subject: Re: Getting the list of members in an AD group This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attachments. ********************************************************************** 2014-04-11 19:11 GMT+05:30 Jon C Kidder <jckidder(a)aep.com&gt;: How do I get the members list via openldap with ranging ? I tried googling this but could not get much information about ranging or getting the "Domain Users" group members ? Can you point me to some relevant link ? Thanks. Sankar

2014-05-02 18:12 GMT+05:30 Jon C Kidder <jckidder(a)aep.com&gt;: Unfortunately even this does not work with the "Domain Users" group. I was able to get the members of any custom groups that the administrator has created but a query on the default "Domain Users" group returns just null. -- Sankar P http://psankar.blogspot.com

Sankar P wrote: Yes. "Domain Users" is a primary group, membership is stored in the user object. -- Harry Jede

Couple of quick corrections. Primary Groups are in Windows for UNIX/POSIX type use; it had nothing to do with hybrid NT/AD domains. Windows nor Windows NT really didn't care about that value; 99%+ Windows environments that I have seen (literally thousands) the primarygroup ID is Domain Users with a smattering of Domain Admins. Companies (usually larger companies) that had UNIX apps bumping up against Windows file servers or apps ported to Windows from UNIX would make use of the primarygroup and those companies would switch the values up as needed. SFU later added in a Primary Group Name / GID attribute to AD to use for UNIX integration. Only Global and Universal groups in the same domain as the user can be primary groups for a user. Domain Local Groups cannot be Primary Groups and you can't use a Global/Universal group from Domain A as the primary group for a user in Domain B. The storage of primary groups is broken out the way it is because there used to be a fuzzy hard limit on the number of members in a group. If you got above a certain number of members and based on the current memory use on a given DC you could run out of versionstore which would effectively plug up replication. It may unplug itself if you are close to the edge but for really large memberships you could permanently stop replication until the group was trimmed down. That fuzzy limit was ~5000 or so members. Clearly there were many NT4 domains that already had primary groups with more WAY more than 5000 members (the MSFT recommended limit was 40k users, I was personally running one environment with over 80k users in one domain and 60k users in another domain) so they had to come up with an alternate solution - so along came primarygroupid attribute. Windows Server 2003 introduced a new mechanism for storing group memberships (called Linked Values which only works for DN type attributes) and added linked value replication which allowed value level replication for linked attributes (like member) instead of sending the entire group membership every time it changed. If making a generic app or script I completely agree that primary group membership should be handled properly. Ignoring it as a large number of publicly available scripts and code snippets do is wrong and cause of issues for companies that actually use alternate primary group memberships. Depending on the version of the OS you may not be able to search directly for the friendly string format of objectsid. Early on you had to convert it to a blob and send it that way, I think that has been fixed since W2K3 so you generally should be good using it but there is still, unbelievably, a lot of Windows 2000 and even Windows NT out there. The <SID=blah> format is one of two special search base formats available (the other being <GUID=blah> that let you specify something other than a DN for a search base. They require an available global catalog for resolution. See http://msdn.microsoft.com/en-us/library/aa772152(v=vs.85).aspx for more info. For the "unwilling to perform" piece, if you can retrieve the extended error info including the DSID that can help understand what is wrong. That is a weird error for that type of request, normally you would expect something like an invalid DN. [Fri 04/11/2014 20:15:34.38] C:\temp>adfind -b "<SID=S-1-5-21-2219134293-820887505-3664443653-513>" -s base member AdFind V01.47.00cpp Joe Richards (joe(a)joeware.net) October 2012 Using server: TestADI-DC1.testadi.loc:389 Directory: Windows Server 2003 dn:CN=Domain Users,CN=Users,DC=testadi,DC=loc 1 Objects returned [Fri 04/11/2014 20:15:37.70] C:\temp>adfind -b "<SID=S-1-5-21-2219134293-820887505-3664443653->" -s base member -exterr AdFind V01.47.00cpp Joe Richards (joe(a)joeware.net) October 2012 Using server: TestADI-DC1.testadi.loc:389 Directory: Windows Server 2003 ldap_get_next_page_s: [TestADI-DC1.testadi.loc] Error 0x22 (34) - Invalid DN Syntax Extended Error: 0000208F: LdapErr: DSID-0C090654, comment: Error processing name, data 0, vece 0 Objects returned joe