New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DefaultLdapEntryManager find #50

Closed
sysmat opened this Issue Jul 13, 2015 · 13 comments

Comments

Projects
None yet
2 participants
@sysmat
Copy link

sysmat commented Jul 13, 2015

I have user in LDAP(389 Directory Server) whith attribute nsAccountLock, but when I perform find with manager I get all attributes except nsAccountLock from LDAP.

Bean:

@Attribute(name = "nsAccountLock", property = "lock")

If I use SearchRequest without naming attributes I don't get nsAccountLock attribute, but if I explicitly define in search result then I get it.

But in find dosen't get it, what I'm doing wrong?

Regards, Tomaz

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 13, 2015

nsAccountLock atribut is DIRECTORY_OPERATION maybe there is a problem.

So find implementations do search something like that attrs=ALL or explicitly by @Attribute annotations in bean?

Regards, Tomaž

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 13, 2015

Another question is how to handled multi valued attribute with manager and merge function.
Especially how to remove attribute or my explicitly use ModifyOperation and ModifyRequest

Regards, Tomaz

@dfish3r

This comment has been minimized.

Copy link
Member

dfish3r commented Jul 13, 2015

Which version are you using and can you try out the last snapshot?

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 14, 2015

Latest version(downloded today 2015-07-14) and nsAccountLock(operational attribute) atribut not mapped

@dfish3r

This comment has been minimized.

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 15, 2015

Maybe I'm doing something wrong.

  1. I download ldaptive-master.zip
  2. I deployed as snapshot in my local nexus
  3. Run application with latest snapshot

UserLdap Bean:

....
@Attribute(name = "nsAccountLock", property = "nsAccountLock"),
@Attribute(name = "objectClass", values = {"top","person","inetOrgPerson","organizationalPerson","posixAccount","shadowAccount","eduPerson"
,"schacContactLocation","schacEmployeeInfo","schacEntryConfidentiality","schacEntryMetadata"
,"schacLinkageIdentifiers","schacLinkageIdentifiers","schacPersonalCharacteristics","schacUserEntitlements"})
...
...
private String[] nsAccountLock = new String[0];
...
public String[] getNsAccountLock() {
return nsAccountLock;
}
public void setNsAccountLock(String[] nsAccountLock) {
this.nsAccountLock = nsAccountLock;

}

main class:

UserLdap user = new UserLdap("mcadez@guest.arnes.si");
DefaultLdapEntryMapper mapper = new DefaultLdapEntryMapper();
DefaultLdapEntryManager manager = new DefaultLdapEntryManager(mapper, connFactory);
result = (UserLdap) manager.find(user);

result:

UserLdap{distinguishedName=eduPersonPrincipalName=mcadez@guest.arnes.si,dc=guest,dc=arnes,dc=si;
eduPersonPrincipalName=mcadez@guest.arnes.si;
commonName=Mojca Cadez;
group=9999;
homeDirectory=/out/50/testko909;
surname=Cadez;
username=mcadez;
unixUniqueNumber=31593;
gecos=BlaBla5;

shadowExpire=16741;

Attribute nsAccountLock is empty but in LDAP is set to nsAccountLock=true and with search I get it.

Regards, Tomaz

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 15, 2015

My Ldap is 389 Directory Server version centos-ds-8.2.0-2.el5.centos

nsAccountLock is DIRECTORY_OPERATION aka operational attribute and server will NOT return it if not explicitly defined in request.

Regards, Tomaz

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 15, 2015

My LDAP log:

Jul 15 10:26:10 conn=1062 fd=81 slot=81 connection from 193.2.1.179 to 193.2.18.199
Jul 15 10:26:10 conn=1062 op=0 BIND dn="eduPersonPrincipalName=root@guest.arnes.si,dc=guest,dc=arnes,dc=si" method=128 version=3
Jul 15 10:26:10 conn=1062 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="edupersonprincipalname=root@guest.arnes.si,dc=guest,dc=arnes,dc=si"
Jul 15 10:26:10 conn=1062 op=1 SRCH base="eduPersonPrincipalName=mcadez@guest.arnes.si,dc=guest,dc=arnes,dc=si" scope=0 filter='(objectClass= * )' attrs=' * + aci'
Jul 15 10:26:10 conn=1062 op=1 RESULT err=0 tag=101 nentries=1 etime=0
Jul 15 10:26:10 conn=1062 op=2 UNBIND
Jul 15 10:26:10 conn=1062 op=2 fd=81 closed - U1

@dfish3r

This comment has been minimized.

Copy link
Member

dfish3r commented Jul 15, 2015

I'm still not certain you're running the latest version.
I think this bug was fixed here:
41706d4#diff-f8691fe6607c2cc207e59541fa48e524
Which would include all operational attributes by default.

Please make sure you're using this version:
https://github.com/vt-middleware/maven-repo/blob/master/org/ldaptive/ldaptive/1.1.0-SNAPSHOT/ldaptive-1.1.0-20150714.175201-2.jar?raw=true
Or build the latest version from the master branch.

@dfish3r

This comment has been minimized.

Copy link
Member

dfish3r commented Jul 15, 2015

You can perform a simple test from the command line which mimics the search:

ldapsearch -H ldap://my.directory.org:389 -x \
-b 'eduPersonPrincipalName=mcadez@guest.arnes.si,dc=guest,dc=arnes,dc=si' \
-s base '(objectClass=*)' '*' '+'

If that search does not return the attribute you're locking for, then I'll have to provide some way for you to inject attribute names into the LdapEntryManager so they can be added to search.

@sysmat

This comment has been minimized.

Copy link

sysmat commented Jul 16, 2015

As I understand Ldap(389 Directory Serve) for returning operational attributes they should be explicitly requested.

http://directory.fedoraproject.org/docs/389ds/howto/howto-operationalattributes.html

I though that manager 'scan' attributes in annotation @Entry and adding them in request

Regards, Tomaž

@dfish3r

This comment has been minimized.

Copy link
Member

dfish3r commented Jul 17, 2015

Sounds like this particular directory server does not support the plus (+) syntax for returning all operational attributes.

I'll add support for specifying attribute names to be included in the search.

dfish3r added a commit that referenced this issue Jul 17, 2015

@dfish3r

This comment has been minimized.

Copy link
Member

dfish3r commented Aug 25, 2015

Fixed in c26c651

@dfish3r dfish3r closed this Aug 25, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment