[389-users] Re: ldapsearch and 389ds

> On 06/02/2016 03:22 PM, Job Cacka wrote:
> It is another set of client tools for accessing a directory server(it
> uses the same names: ldapsearch, ldapmodify, etc). It works just fine,
> as does the openldap version. Its command line usage is different
> though, especially when using SSL.
>
> I would stick with the openldap version.
> What do you mean different
> results? How are you tweaking it, and what
> are you expecting?
See Below.
> This is actually not a good way to back things up at the moment since
> currently you have to list all the attributes that might be possible,
> and all the operational attributes you might need for things like
> password policy, etc.
>
> It's best to use db2bak.pl, or db2ldif.pl for backup purposes.
Thanks!
> No.
> When
> you say schema, do mean listing all the objectclasses and
> attributes that are currently configured for the server? This is done by:
>
> ldapsearch -D "cn=directory manager" -W -b "cn=schema"
> 'objectclass=*'
> attributetypes objectclasses
> ldapsearch -D "cn=directory
> manager" -W -b "YOURSUFFIX" uid=USERID
>
> Or change the filter to "uid=*" to see all the "user" entries. Or use
>
> objectclass=* to dump every entry. All the standard attributes are
> returned unless there are access control rules in place to block them.
> However, binding as "cn=directory manager" will bypass all access controls.

Ok, maybe this is what I don't understand or it is broken. If I execute the following commands I get the same results.

ldapsearch -H ldaps://ds1.domain.com [-x] -D "cn=directory manager" -w "pass" -b "dc=domain,dc=com" "uid=*"
ldapsearch -H ldaps://ds1.domain.com [-x] -D "cn=directory manager" -w "pass" -b "dc=domain,dc=com" uid=USERID
ldapsearch -H ldaps://ds1.domain.com [-x] -D "cn=directory manager" -w "pass" -b "dc=domain,dc=com" uid=XYZ
ldapsearch -H ldaps://ds1.domain.com [-x] -D "cn=directory manager" -w "pass" -b "dc=domain,dc=com" uid=USERID,ou=USERS,dc=domain,dc=com

What I am trying to do is choose a user and see all of the populated attributes. Then compare a known working user with one that is having trouble. At least then I can rule out the ldap permissions which should have been the same because they were created using a scripted smbldap-adduser command.

> You can use
> the getEffectRights control:
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10...
>
This documentation will take some time to digest, but it looks like what I was looking for or it is at least in the right direction. I would like to see what rights the uid=admin user has for an entry:
"dn: cn=Domain Users,ou=GROUPS,dc=domain,dc=com" and compare them to "cn=directory manager"

> Regards,
> Mark

Thanks Mark
--
389-users mailing list
389-users@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-users@lists.fedoraproject.org