« Return to Thread: Solaris native ldap client to Windows Active Directory: Netgroups don't work because of control critical statement

Re: Solaris native ldap client to Windows Active Directory: Netgroupsdon't work because of control critical statement

by Markus Moeller :: Rate this Message:

Reply to Author | View in Thread


"Thomas Glanzmann" <thomas@...> wrote in message
news:20090416093201.GA17830@......

> 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)?
>

2. Disable Virtual List Views (VLV)  on Windows AD (use for example:
ntdsutil "configurable settings" connections "connect to domain
domain.com" quit "show values" quit quit
to list values)
(Solaris attempts to use it but fails because of limited support in Windows)


>        Thomas
>

Regards
Markus


 « Return to Thread: Solaris native ldap client to Windows Active Directory: Netgroups don't work because of control critical statement