lists.arthurdejong.org
RSS feed

[nssldap] Solaris native ldap client to Windows Active Directory: Netgroups don't work because of control critical statement

[Date Prev][Date Next] [Thread Prev][Thread Next]

[nssldap] Solaris native ldap client to Windows Active Directory: Netgroups don't work because of control critical statement



Hello list,
I'm trying to bind a Solaris 10 Update 6 to a Windows Active Directory. Users
and Groups are working, but netgroups don't work. What I did is that I used
snoop to capture the ldap query and the following showed up:

I used the following command line to configure ldapclient:

No.     Time        Source                Destination           Protocol Info
      7 0.006628    157.163.247.19        157.163.248.31        LDAP     32919 
> ldap [PSH, ACK] Seq=106 Ack=23 Win=49640 [TCP CHECKSUM INCORRECT] Len=285| 
searchRequest(2) "OU=Netgroups,OU=ErlF,OU=U
NIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net" wholeSubtree

Lightweight-Directory-Access-Protocol
    LDAPMessage searchRequest(2) 
"OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net" 
wholeSubtree
        messageID: 2
        protocolOp: searchRequest (3)
            searchRequest
                baseObject: 
OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
                scope: wholeSubtree (2)
                derefAliases: derefAlways (3)
                sizeLimit: 0
                timeLimit: 30
                typesOnly: False
                Filter: (&(objectClass=nisNetGroup)(cn=netgroup))

                attributes: 2 items
                    Item: nisnetgrouptriple
                    Item: membernisnetgroup
        [Response In: 8]
        controls: 2 items
            Item
                controlType: 1.2.840.113556.1.4.473 (sortKeyList)
                criticality: True
                SortKeyList: 2 items
                    Item
                        attributeType: cn
                    Item
                        attributeType: uid
            Item
                controlType: 2.16.840.1.113730.3.4.9 (LDAP_CONTROL_VLVREQUEST 
VLV)
                criticality: True
                controlValue: 300F020100020203E7A006020101020100

No.     Time        Source                Destination           Protocol Info
      8 0.007149    157.163.248.31        157.163.247.19        LDAP     
searchResDone(2) unavailableCriticalExtension (00000057: LdapErr: 
DSID-0C09068F, comment: Error processing control, data 0, ve
ce)  [0 results]

Lightweight-Directory-Access-Protocol
    LDAPMessage searchResDone(2) unavailableCriticalExtension (00000057: 
LdapErr: DSID-0C09068F, comment: Error processing control, data 0, vece) [0 
results]
        messageID: 2
        protocolOp: searchResDone (5)
            searchResDone
                resultCode: unavailableCriticalExtension (12)
                matchedDN:
                errorMessage: 00000057: LdapErr: DSID-0C09068F, comment: Error 
processing control, data 0, vece
        [Response To: 7]
        [Time: 0.000521000 seconds]

What I don't get here is what the ,,controls: 2 items'' is about. It seems to
be an enhanced query that uses some advanved ldap protocol ability that my
server doesn't seem to understand. If I manually do the very same query
and leave the control out in a perl script, I get the result that I
would have assumed:

(ad027088pc) [~/work/ldap] cat demonstrate.pl
#!/usr/bin/perl -w

use strict;
use warnings FATAL => 'all';

use Net::LDAP;

my $ldap = Net::LDAP->new("deerlf0a90.ww004.glanzmann.net", version => 3);
my $mesg = undef;
my $result = undef;

$mesg = 
$ldap->bind("CN=ADLDAPF,OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net",
 password => 'password here') || die ("Could not authenticate: $!");
$mesg->code && die $mesg->error;

$mesg = $ldap->search(filter=>"(&(objectClass=nisNetGroup)(cn=umc_test))", 
attrs => ['nisnetgrouptriple', 'membernisnetgroup'],
base => 
"OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net");
$mesg->code && die $mesg->error;

my @entries = $mesg->entries;
for my $entry (@entries) {
        $entry->dump;
}

$ldap->unbind;
(ad027088pc) [~/work/ldap] ./demonstrate.pl
------------------------------------------------------------------------
dn:CN=umc_test,OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net

nisNetgroupTriple: (deerlf0x23.erlf.glanzmann.de,-,)
                   (deerlf0x23,-,)
                   (deerlf0v51,-,)
                   (deerlf0v51.erlf.glanzmann.de,-,)
                   (erld624x.erlf.glanzmann.de,-,)
                   (ad027088pc,-,)
                   (ad027088pc.erlf.glanzmann.de,-,)

This is how I configured the ldapclient:

ldapclient -v  manual \
        -a credentialLevel=proxy \
        -a authenticationMethod=simple \
        -a 
proxyDN=CN=ADLDAPF,OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
 \
        -a proxyPassword=z61pAEQMsz61pAEQMs \
        -a 
defaultSearchBase=OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net
 \
        -a domainName=erlf.glanzmann.de \
        -a defaultServerList=157.163.248.31 \
        -a attributeMap=group:userpassword=userPassword \
        -a attributeMap=group:memberuid=memberUid \
        -a attributeMap=group:gidnumber=gidNumber \
        -a attributeMap=passwd:gecos=cn \
        -a attributeMap=passwd:gidnumber=gidNumber \
        -a attributeMap=passwd:uidnumber=uidNumber \
        -a attributeMap=passwd:homedirectory=unixHomeDirectory \
        -a attributeMap=passwd:loginshell=loginShell \
        -a attributeMap=shadow:shadowflag=shadowFlag \
        -a attributeMap=shadow:userpassword=userPassword \
        -a objectClassMap=group:posixGroup=group \
        -a objectClassMap=passwd:posixAccount=user \
        -a objectClassMap=shadow:shadowAccount=user \
        -a 
serviceSearchDescriptor=passwd:OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net?sub
 \
        -a 
serviceSearchDescriptor=group:OU=ErlF,OU=User,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net?sub
 \
        -a 
serviceSearchDescriptor=netgroup:OU=Netgroups,OU=ErlF,OU=UNIX,OU=_CentralServices,DC=ww004,DC=glanzmann,DC=net?sub

And now my questions:

        - Can I tell Sun's native client to don't use the ,,control''
          statements? For users and groups it doesn't use a control statement
          in the query.

        - Or is the problem caused by a misconfiguration and/or missing
          objects in my Active Directory (nss-ldap works with that out
          of the box)?

        Thomas