Hi,
We're having an issue with a slightly older version of openldap. (2.4.23-26 on CentOS). Using Apache Directory Studio I do a search:
"(objectclass=person)" on a search base of "ou=People,dc=example,dc=com"
This should be the easiest and simplest search in the world. However, I get entries like :
dn: uid=PLACEHOLDER_example_agent,ou=People,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson cn: PLACEHOLDER_example agent gidNumber: 100 homeDirectory: /home/example_agent sn: agent uid: PLACEHOLDER_example_agent uidNumber: 621 givenName: example loginShell: /bin/bash userPassword:: DELETED
and
dn: uid=BDTestUser,ou=People,dc=example,dc=com objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson cn: BD sn: User displayName: BD User givenName: BD mail: seo@example.com mobile: +1 1111111111 ou: Sales telephoneNumber: +1 222222222 title: BD Sample User uid: BDTestUser userPassword:: DELETED
Where am I going wrong?
Tuc
On Fri, May 16, 2014 at 7:13 AM, Tuc ml@t-b-o-h.net wrote:
We're having an issue with a slightly older version of openldap. (2.4.23-26 on CentOS). Using Apache Directory Studio I do a search:
"(objectclass=person)" on a search base of "ou=People,dc=example,dc=com"
This should be the easiest and simplest search in the world. However, I get entries like :
dn: uid=PLACEHOLDER_example_agent,ou=People,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson cn: PLACEHOLDER_example agent gidNumber: 100 homeDirectory: /home/example_agent sn: agent uid: PLACEHOLDER_example_agent uidNumber: 621 givenName: example loginShell: /bin/bash userPassword:: DELETED
and
dn: uid=BDTestUser,ou=People,dc=example,dc=com objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson cn: BD sn: User displayName: BD User givenName: BD mail: seo@example.com mobile: +1 1111111111 ou: Sales telephoneNumber: +1 222222222 title: BD Sample User uid: BDTestUser userPassword:: DELETED
Where am I going wrong?
organizationalPerson is a subclass of person, and inetOrgPerson is a subclass of organizationalPerson, so the entries above implicitly have the person objectClass. Have a look through the schema files.
On 2014-05-16 11:33, Ryan Tandy wrote:
On Fri, May 16, 2014 at 7:13 AM, Tuc ml@t-b-o-h.net wrote:
We're having an issue with a slightly older version of openldap. (2.4.23-26 on CentOS). Using Apache Directory Studio I do a search:
"(objectclass=person)" on a search base of "ou=People,dc=example,dc=com"
This should be the easiest and simplest search in the world. However, I get entries like :
dn: uid=PLACEHOLDER_example_agent,ou=People,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson cn: PLACEHOLDER_example agent gidNumber: 100 homeDirectory: /home/example_agent sn: agent uid: PLACEHOLDER_example_agent uidNumber: 621 givenName: example loginShell: /bin/bash userPassword:: DELETED
and
dn: uid=BDTestUser,ou=People,dc=example,dc=com objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson cn: BD sn: User displayName: BD User givenName: BD mail: seo@example.com mobile: +1 1111111111 ou: Sales telephoneNumber: +1 222222222 title: BD Sample User uid: BDTestUser userPassword:: DELETED
Where am I going wrong?
organizationalPerson is a subclass of person, and inetOrgPerson is a subclass of organizationalPerson, so the entries above implicitly have the person objectClass. Have a look through the schema files.
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson cn: DELETED gidNumber: 100 homeDirectory: /home/tuc sn: DELETED uid: tuc uidNumber: DELETED dialupAccess: TRUE displayName: DELETED givenName: DELETED loginShell: /bin/bash mail: tuc@example.com mobile: +1 DEL ETE D!!! ou: Tech telephoneNumber: +1 DEL ETE D!!! title: Network Janitor userPassword:: DELETED
On Fri, May 16, 2014 at 8:59 AM, Tuc ml@t-b-o-h.net wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
An entry matching (objectClass=organizationalPerson) also satisfies (objectClass=person) whether or not you write it explicitly. You can ask for (&(objectClass=organizationalPerson)(!(objectClass=person))) but there won't be any results.
Can you back up a few steps and explain the underlying problem you're trying to solve?
On 2014-05-16 12:14, Ryan Tandy wrote:
On Fri, May 16, 2014 at 8:59 AM, Tuc ml@t-b-o-h.net wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
An entry matching (objectClass=organizationalPerson) also satisfies (objectClass=person) whether or not you write it explicitly. You can ask for (&(objectClass=organizationalPerson)(!(objectClass=person))) but there won't be any results.
Can you back up a few steps and explain the underlying problem you're trying to solve?
Hi,
Basically, we have a legacy LDAP that we're trying to deal with. We have a bunch of id's that are created in the "ou=People" that really aren't people, they're service accounts/application accounts/who knows WHERE they are. We also have a mobile app that through an API pulls our company directory. Management gets a bit annoyed when they see "Jenkins" (Build system), "BDTestUser", etc as company employees. We thought that simply taking the "ObjectClass: person" off the individual records would allow us to just search for the ones without it explicitly stated and we could work on moving the offenders to our "SVC_Account" OU. But we do the search and it just returns everything.
Tuc
On Fri, May 16, 2014 at 10:54 AM, Tuc ml@t-b-o-h.net wrote:
Basically, we have a legacy LDAP that we're trying to deal with. We have a bunch of id's that are created in the "ou=People" that really aren't people, they're service accounts/application accounts/who knows WHERE they are. We also have a mobile app that through an API pulls our company directory. Management gets a bit annoyed when they see "Jenkins" (Build system), "BDTestUser", etc as company employees. We thought that simply taking the "ObjectClass: person" off the individual records would allow us to just search for the ones without it explicitly stated and we could work on moving the offenders to our "SVC_Account" OU. But we do the search and it just returns everything.
Unfortunately that won't work, because of the objectClass inheritance. Maybe there's some other value (looking at your examples above, radiusProfile or pwmUser?) that you could search for.
Tuc wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
I think there's a misunderstanding on your side: If an entry has 'inetOrgPerson' as its structural object class it also has object classes 'organizationalPerson' and 'person' no matter whether those attributes values were added to attribute 'objectClass'.
You should try to describe what you really want to finally achieve.
Ciao, Michael.
Michael Ströder wrote:
Tuc wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
I think there's a misunderstanding on your side: If an entry has 'inetOrgPerson' as its structural object class it also has object classes 'organizationalPerson' and 'person' no matter whether those attributes values were added to attribute 'objectClass'.
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
You should try to describe what you really want to finally achieve.
Howard Chu wrote:
Michael Ströder wrote:
Tuc wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
I think there's a misunderstanding on your side: If an entry has 'inetOrgPerson' as its structural object class it also has object classes 'organizationalPerson' and 'person' no matter whether those attributes values were added to attribute 'objectClass'.
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
Yes, but you won't get results for
(&(objectclass=inetorgperson)(!(objectclass=person)))
I'm not sure what the original poster really wants though. The cited text above is not really clear on that.
Ciao, Michael.
--On May 16, 2014 at 10:02:04 AM -0700 Howard Chu hyc@symas.com wrote:
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
(&(objectclass=person)(!(objectclass=inetorgperson))(!(objectclass= organizationalPerson)))
would probably be even better as far as achieving their stated objective, if what they want is object that only have "person".
--Quanah
On 2014-05-16 13:42, Quanah Gibson-Mount wrote:
--On May 16, 2014 at 10:02:04 AM -0700 Howard Chu hyc@symas.com wrote:
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
(&(objectclass=person)(!(objectclass=inetorgperson))(!(objectclass= organizationalPerson)))
would probably be even better as far as achieving their stated objective, if what they want is object that only have "person".
--Quanah
Also completely empty for basedn and ou=People.
Tuc
--On May 16, 2014 at 2:00:22 PM -0400 Tuc ml@t-b-o-h.net wrote:
Also completely empty for basedn and ou=People.
Then you have no objects that *only* have person as the objectClass. Since you've never once stated what your objective is, I can only assume this answers the question you wanted an answer to.
--Quanah
Tuc wrote:
On 2014-05-16 13:42, Quanah Gibson-Mount wrote:
--On May 16, 2014 at 10:02:04 AM -0700 Howard Chu hyc@symas.com wrote:
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
(&(objectclass=person)(!(objectclass=inetorgperson))(!(objectclass= organizationalPerson)))
would probably be even better as far as achieving their stated objective, if what they want is object that only have "person".
Also completely empty for basedn and ou=People.
You fail to precisely describe what you want to achieve even after being asked => I give up wasting my time.
Ciao, Michael.
On 2014-05-16 14:27, Michael Ströder wrote:
You fail to precisely describe what you want to achieve even after being asked => I give up wasting my time.
Ciao, Michael.
Did this not make the list? I sent it as soon as someone asked what my real objective was.
Hi,
Basically, we have a legacy LDAP that we're trying to deal with. We have a bunch of id's that are created in the "ou=People" that really aren't people, they're service accounts/application accounts/who knows WHERE they are. We also have a mobile app that through an API pulls our company directory. Management gets a bit annoyed when they see "Jenkins" (Build system), "BDTestUser", etc as company employees. We thought that simply taking the "ObjectClass: person" off the individual records would allow us to just search for the ones without it explicitly stated and we could work on moving the offenders to our "SVC_Account" OU. But we do the search and it just returns everything.
Tuc
Quanah Gibson-Mount wrote:
--On May 16, 2014 at 10:02:04 AM -0700 Howard Chu hyc@symas.com wrote:
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
(&(objectclass=person)(!(objectclass=inetorgperson))(!(objectclass= organizationalPerson)))
would probably be even better as far as achieving their stated objective, if what they want is object that only have "person".
If so, then they should just use (&(objectclass=person)(!(objectclass=organizationalperson)))
since that will automatically exclude inetorgperson too.
On 2014-05-16 13:02, Howard Chu wrote:
Michael Ströder wrote:
Tuc wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
I think there's a misunderstanding on your side: If an entry has 'inetOrgPerson' as its structural object class it also has object classes 'organizationalPerson' and 'person' no matter whether those attributes values were added to attribute 'objectClass'.
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
You should try to describe what you really want to finally achieve.
If I do that filter on my ou=People, I get nothing. If I do it on our base DN,I actually end up with all our service accounts.
Tuc
Tuc wrote:
On 2014-05-16 13:02, Howard Chu wrote:
Michael Ströder wrote:
Tuc wrote:
Is there some way I can modify the query to only get ones that would look like :
dn: uid=tuc,ou=People,dc=example,dc=com objectClass: radiusprofile objectClass: pwmUser objectClass: top VVVVVVVVVVVVVVVVVVV objectClass: person ^^^^^^^^^^^^^^^^^^^ objectClass: posixAccount objectClass: organizationalPerson objectClass: inetOrgPerson
I think there's a misunderstanding on your side: If an entry has 'inetOrgPerson' as its structural object class it also has object classes 'organizationalPerson' and 'person' no matter whether those attributes values were added to attribute 'objectClass'.
But you could, of course, filter on (&(objectclass=person)(!(objectclass=inetorgperson))) if you wanted.
You should try to describe what you really want to finally achieve.
If I do that filter on my ou=People, I get nothing. If I do it on our base DN,I actually end up with all our service accounts.
Sounds like exactly what the filter should do. To get just the people, invert the filter again. If you don't understand boolean logic, you need more help than you should expect from this list.
Tuc wrote:
We're having an issue with a slightly older version of openldap. (2.4.23-26 on CentOS). Using Apache Directory Studio I do a search:
"(objectclass=person)" on a search base of "ou=People,dc=example,dc=com"
This should be the easiest and simplest search in the world. However, I get entries like :
Could you please elaborate on what result you expected?
dn: uid=PLACEHOLDER_example_agent,ou=People,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson [..] and
dn: uid=BDTestUser,ou=People,dc=example,dc=com objectClass: top objectClass: organizationalPerson objectClass: inetOrgPerson [..]
Given inetOrgPerson SUP organizationalPerson SUP person this result looks perfectly fine to me.
Also note that even attributes can also be sub-classed (SUP).
Ciao, Michael.
openldap-technical@openldap.org
-
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount -
Ryan Tandy -
Tuc