> 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@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
