AD attributes queried by 'id DOMAIN/user'

C.J. Adams-Collier KF7BMP cjac at colliertech.org
Wed May 29 13:04:40 MDT 2013


From tcpdump, I discovered that the query is thus:


    LDAPMessage searchRequest(7) "dc=REDACTED,dc=NET" wholeSubtree
        messageID: 7
        protocolOp: searchRequest (3)
            searchRequest
                baseObject: dc=REDACTED,dc=NET
                scope: wholeSubtree (2)
                derefAliases: neverDerefAliases (0)
                sizeLimit: 0
                timeLimit: 15
                typesOnly: False
                Filter: (objectSid=01:05:00:00:00:00:00:05:15:00:00:00:d5:cb:5c:58:92:e0:3c:77:82:8b:a6:28:06:43:04:00)
                    filter: equalityMatch (3)
                        equalityMatch
                attributes: 2 items
        [Response In: 11627]
        controls: 3 items


And the response is thus:


        Lightweight Directory Access Protocol
            LDAPMessage searchResEntry(7) "<GUID=5107301612c3e143a94c836d700cfea7>;<SID=010500000000000515000000d5cb5c5892e03c77828ba62806430400>;CN=UNIX-support1,OU=Unix-Imported,OU=Groups,OU=Common,DC=redacted,DC=net" [1 result]
                messageID: 7
                protocolOp: searchResEntry (4)
                    searchResEntry
                [Response To: 11263]
                [Time: 5.441994000 seconds]
        Lightweight Directory Access Protocol
            LDAPMessage searchResDone(7) success [1 result]
                messageID: 7
                protocolOp: searchResDone (5)
                    searchResDone
        

As you can see, the response time is less than awesome.  So my next
question is this: Can I tell winbindd to issue LDAP queries for SID to
group name mappings starting at the
OU=Unix-Imported,OU=Groups,OU=Common,DC=redacted,DC=net baseObject
rather than all the way down at DC=redacted,DC=net?  This would
substantially reduce the size of the haystack through which we search
for the needle.  I understand that increasing the memory allocated to
the AD domain controller and ensuring that the attributes are properly
indexed should improve this as well, but I'd like to do as much as I can
from the client side.

Cheers,

C.J.


On Tue, 2013-05-28 at 10:24 -0700, C.J. Adams-Collier KF7BMP wrote:

> Hey folks,
> 
> We're experiencing some long delays getting responses back from winbind
> via nsswitch.  Do any of you know off the top of your head which AD
> attributes are being queried by id via nsswitch?  I could walk through
> nss_winbind_linux.c with gdb, but that doesn't sound like a fun way to
> spend my day.
> 
> Thanks in advance,
> 
> C.J.
> 
> -- some timing statistics below --
> 
> t-s-freebsd7# time wbinfo -r DOMAIN/cjac
> 707
> 101
> 0.000u 0.006s 0:00.14 0.0%      0+0k 0+0io 0pf+0w
> t-s-freebsd7# time sh -c 'for gid in 707 101 ; do wbinfo --gid-info=$gid > /dev/null ; done'
> 0.018u 0.000s 0:00.23 4.3%      1524+2380k 0+0io 0pf+0w
> t-s-freebsd7# time wbinfo -i DOMAIN/cjac
> cjac:*:29906:707:Carl Adams-Collier:/homes/cjac:/bin/bash
> 0.000u 0.006s 0:00.01 0.0%      0+0k 0+0io 0pf+0w
> t-s-freebsd7# time id DOMAIN/cjac
> uid=29906(cjac) gid=707(unix-support1) groups=707(unix-support1)
> 0.009u 0.079s 0:04.36 1.6%      10+1100k 0+0io 0pf+0w
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20130529/b58e2eeb/attachment.pgp>


More information about the samba-technical mailing list