On 06/02/2016 03:22 PM, Job Cacka wrote:
I have been looking for a comprehensive, easy to understand writeup on how to use ldapsearch.
Why?
I am troubleshooting a connectivity problem, that may be related to SSL/TLS, or some change to that config.
OR
it may be related to permissions.
The problem manifested itself several months ago. In troubleshooting the issues I discovered some basic connectivity problems that I believe are solved. I was attempting to use ldapsearch and had several questions.
This is what is installed at the 389 DS:
389-admin-1.1.29-1.el6.x86_64
389-console-1.1.7-1.el6.noarch
389-dsgw-1.1.10-1.el6.x86_64
389-ds-base-libs-1.2.11.15-22.el6_4.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-1.2.2-1.el6.noarch
389-ds-base-1.2.11.15-22.el6_4.x86_64
389-ds-console-doc-1.2.6-1.el6.noarch
389-adminutil-1.1.15-1.el6.x86_64
389-admin-console-doc-1.1.8-1.el6.noarch
389-admin-console-1.1.8-1.el6.noarch
From 389 console:
Directory server:
Installation date: October 4, 2013 10:49:53 AM PDT
version:1.2.11.15
build:2013.238.2155
Admin server:
version:1.1.29
build:2012.087.1433
This was setup and then the configuration modified to use SSL/TLS so the directory server runs on port 636.
So for my questions:
What is mozldap-tools and should I be using that version of ldapsearch? I found several references searching for information on how to use ldapsearch that were confusing.
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.
I would normally test connectivity to the server from the client with a command like (modified to protect the guilty):
ldapsearch -H ldaps://ds1.domain.com [-x] -D "cn=directory manager" -W "cn=admin-serv-ds1,cn=389 Administration Server,cn=Server Group,cn=ds1.domain.com,ou=domain.com,o=NetscapeRoot"
This produces results, but it seems like when I experiment with it I always get the same results, or just slightly different results.
What variations should produce different results?
What do you mean different results? How are you tweaking it, and what
are you expecting?
How can I show all of the attributes for all of the entries? Is that smart? I thought this saved to a file would help in an emergency backup situation.
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.
Can ldapsearch break anything?
No.
How can I use it to check schema? Is there a better way?
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
How can I use it to determine if a user exists, and if so what are his attributes and the contents of the attributes?
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.
How can I see what permissions a user has in 389ds?
You can use the getEffectRights control:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html
Regards,
Mark
I have been pouring over material on the web, but I feel the answers are just a bit more elusive than they ought to be. A guide would be nice. the man page omits examples with authentication. Is there a way to set defaults for the auth to clean up the command?
Thanks,
Job Cacka
--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
--
389-users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/389-users@xxxxxxxxxxxxxxxxxxxxxxx
