open ldap configuration on rhel3-u4
Nilesh Joshi
nileshnjoshi at gmail.com
Tue Aug 18 21:37:40 UTC 2009
Hi,
I think problem got fixed after reediting the slapd.com file.
I am able to do search now.
Thanks and Regards,
-Nilesh
On Mon, Aug 17, 2009 at 12:35 PM, Rick Stevens <ricks at nerd.com> wrote:
> Nilesh Joshi wrote:
>
>> Hi,
>>
>> I have done suggested changes in my slapd.com file. Still I see same
>> issue.
>>
>> When I execute command with -Z option, i see:
>>
>> [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>> "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh"
>> ldap_start_tls: Protocol error (2)
>> additional info: unsupported extended operation
>> ldap_bind: Invalid credentials (49)
>> $
>>
>
> As you can see, the "-Z" forces a TLS startup which we weren't seeing
> before.
>
> My first guess is that your LDAP server or your ldapsearch is not linked
> to the OpenSSL libraries or they're using the GnuTLS libraries. Try
> running ldd against your LDAP server and ldapsearch commands:
>
> ldd `which slapd`
> ldd `which ldapsearch`
>
> Verify that "libssl.so*" is listed before any "libgnutls*" files. If
> you see the libgnutls stuff first AND you use a TLS_CACERTFILE in your
> ldap.conf, then the order of the certificates in that file has to be
> reversed (the CA cert must be the last one in the file). If you're
> using the "TLS_CACERTDIR" option, you may need to rearrange things in
> that directory using the "c_rehash" command that's part of the OpenSSL
> packages.
>
> conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389)
>> conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>> do_extended: unsupported operation "1.3.6.1.4.1.1466.20037"
>> conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation
>> conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128
>> conn=77 op=1 RESULT tag=97 err=49 text=
>> conn=77 fd=10 closed (connection lost
>>
>> Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT IF
>> YOU USE SASL.
>> How can I verify?
>>
>
> Verify that you're using SASL? If you don't use the -Z (or -ZZ) and -x
> options to ldapsearch you're using SASL by default. Note that -x alone
> tries to do a simple bind to the server. That's not allowed by default
> unless you allow V2 anonymous binds to the LDAP server by adding a line
> such as
>
> allow bind_v2 bind_anon_cred bind_anon_dn
>
> to your slapd.conf. You should also comment out the "security" line in
> slapd.conf. This unsecures your server. You should then be able to
> access it using the root DN.
>
> I'd recommend you get an LDAP client such as GQ or ldapvi to look at
> the entries in the database. They'll tell you if the password is
> encrypted or not. If you use ldapvi and you don't see anything in curly
> braces such as "{MD5}" or "{SSHA}" in the userPassword attribute's
> value, then the password is in cleartext and the data you see is the
> password.
>
>
> Hi,
>>>>
>>>> I htink error 49 is not gone till now. It was not showing any output. I
>>>> restarted openladp and started getting same error:
>>>> My slapd.conf looks like below (removed commented lines):
>>>>
>>>> -------------------------------------------------------------------------
>>>> include /etc/openldap/schema/core.schema
>>>> include /etc/openldap/schema/cosine.schema
>>>> include /etc/openldap/schema/inetorgperson.schema
>>>> pidfile /usr/var/run/slapd.pid
>>>> argsfile /usr/var/run/slapd.args
>>>> access to dn.base="" by * read
>>>> access to dn.base="cn=Subschema" by * read
>>>> access to *
>>>> by self write
>>>> by users read
>>>> by anonymous auth
>>>> access to attrs=userPassword
>>>> by anonymous auth
>>>> by self write
>>>> by * none
>>>>
>>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem
>>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem
>>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem
>>>>
>>>> database bdb
>>>> suffix "dc=test,dc=com"
>>>> rootdn "cn=Manager,dc=test,dc=com"
>>>> rootpw XXXX
>>>> directory /usr/var/openldap-data/test.com
>>>> index objectClass eq
>>>>
>>>>
>>>> -----------------------------------------------------------------------------
>>>>
>>>> I think need to concentrate on error=49 only.
>>>>
>>>> You have to be very careful about formatting. If this is an exact cut
>>> and paste, you still have authentication issues.
>>>
>>> A leading space in slapd.conf lines can be used to continue previous
>>> directives if they can take multiple values such as the "access"
>>> directive
>>> can. In the above, you have "access to attrs=userPassword"
>>> as a subdirective of the previous "access" directive.
>>>
>>> Re-edit your config file and make it look like this:
>>>
>>> include /etc/openldap/schema/core.schema
>>> include /etc/openldap/schema/cosine.schema
>>> include /etc/openldap/schema/inetorgperson.schema
>>> pidfile /usr/var/run/slapd.pid
>>> argsfile /usr/var/run/slapd.args
>>>
>>> access to dn.base="" by * read
>>>
>>> access to dn.base="cn=Subschema" by * read
>>>
>>> access to *
>>> by self write
>>> by users read
>>> by anonymous auth
>>> access to attrs=userPassword
>>> by anonymous auth
>>> by self write
>>> by * none
>>>
>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem
>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem
>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem
>>>
>>> database bdb
>>> suffix "dc=test,dc=com"
>>> rootdn "cn=Manager,dc=test,dc=com"
>>> rootpw XXXX
>>> directory /usr/var/openldap-data/test.com
>>> index objectClass eq
>>>
>>> I suspect that's where things are getting weird. Personally, I prefer
>>> to indent my access directives, so the above bit would look like:
>>> ---------------------------------------
>>> access to dn.base=""
>>> by * read
>>>
>>> access to dn.base="cn=Subschema"
>>> by * read
>>>
>>> access to *
>>> by self write
>>> by users read
>>> by anonymous auth
>>>
>>> access to attrs=userPassword
>>> by anonymous auth
>>> by self write
>>> by * none
>>> ---------------------------------------
>>> But that's just me.
>>>
>>> Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not being
>>> used, so you're using simple SASL authentication...and again the
>>> passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most
>>> Linux systems will use an MD5 encryption and that won't work with SASL.
>>>
>>> You might also want to try adding "-d 255" to the ldapsearch command.
>>> That will spit out lots of debug info that may help you sort out just
>>> exactly where the thing's dying.
>>>
>>>
>>>
>>> What you say?
>>>>
>>>> Regards,
>>>> -Nilesh
>>>> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens <ricks at nerd.com> wrote:
>>>>
>>>> Nilesh Joshi wrote:
>>>>
>>>>> Hi Rick,
>>>>>
>>>>>> I have generated cert again and started slapd.
>>>>>>
>>>>>> Now I see following in logs:
>>>>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389)
>>>>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128
>>>>>> It's same for below 2 commands:
>>>>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh"
>>>>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh"
>>>>>>
>>>>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and
>>>>>> restarted
>>>>>> openldap, the result is same.
>>>>>>
>>>>>> It looks like error 49 is gone.
>>>>>>
>>>>>> Ok, if error 49 is gone, but you're not getting any data back, then
>>>>>>
>>>>> user "nilesh" probably doesn't have read access to the database. If
>>>>> you have your slapd manual handy, read up on the "access" directives.
>>>>>
>>>>> If you want a user to see any and all of their info, then you need a
>>>>> directive such as:
>>>>>
>>>>> access to *
>>>>> by self read
>>>>> by * none
>>>>>
>>>>> in slapd.conf. That permits someone to read their own data. If you
>>>>> want to let them modify their data:
>>>>>
>>>>> access to *
>>>>> by self write
>>>>> by * none
>>>>>
>>>>> (note that "write" permission also includes all lower permissions such
>>>>> as auth, read, search, etc.)
>>>>>
>>>>> What else I need to do to fix this issue.
>>>>> Looks like you're authenticating fine now, but you have to set up
>>>>> access
>>>>> rules to allow users to see things. Here's a good on-line reference
>>>>> book on how to manage an LDAP server:
>>>>>
>>>>> http://www.zytrax.dom/books/ldap
>>>>>
>>>>> Also, the OpenLDAP System Admin Guide should have been placed in
>>>>>
>>>>> /usr/share/doc/openldap-servers-version/guide.html
>>>>>
>>>>> (replace "version" with the appropriate version number) when you
>>>>> installed the OpenLDAP server RPM. You can view it by opening a
>>>>> browser
>>>>> and going to
>>>>>
>>>>> file:///usr/share/doc/opeenldap-servers-version/guide.html
>>>>>
>>>>>
>>>>>
>>>>> Thanks and Regards,
>>>>>
>>>>>> -Nilesh
>>>>>>
>>>>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens <ricks at nerd.com>
>>>>>> wrote:
>>>>>>
>>>>>> Nilesh Joshi wrote:
>>>>>>
>>>>>> Thanks Rick.
>>>>>>>
>>>>>>> I have checked using -w password. The exact command I tried was:
>>>>>>>>
>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)'
>>>>>>>>
>>>>>>>> Did you enclose the password in single quotes to mask its value?
>>>>>>>>
>>>>>>>> Also added:
>>>>>>>
>>>>>>> access to attrs=userPassword
>>>>>>>
>>>>>>>> by anonymous auth
>>>>>>>> by self write
>>>>>>>> by * none
>>>>>>>>
>>>>>>>> That may not be adequate. That simply allows a user to authenticate
>>>>>>>>
>>>>>>>> against the LDAP database. It does NOT allow a regular user to
>>>>>>> search
>>>>>>> the entire database. Let's get rid of the error 49 first, then we'll
>>>>>>> worry about the rest.
>>>>>>>
>>>>>>> However the result was same. I have confirmed that password is
>>>>>>> password
>>>>>>> for
>>>>>>>
>>>>>>> now.
>>>>>>>
>>>>>>>> If you're using SASL, remember that all the passwords must be stored
>>>>>>>> in
>>>>>>>>
>>>>>>>> cleartext. If the password you're going to use is in the LDAP
>>>>>>> database,
>>>>>>> it must be stored in cleartext--NOT some excrypted format such as
>>>>>>>
>>>>>>> {MD5} cypherstring
>>>>>>> {SSHA} cypherstring
>>>>>>>
>>>>>>> If the password is in the Cyrus SASL database, it too has to be in
>>>>>>> cleartext. This is one of the weaknesses of SASL.
>>>>>>>
>>>>>>> If you're going to use encrypted passwords in the database, you'll
>>>>>>> need
>>>>>>> to use SSL or KRB5 as the transport mechanism.
>>>>>>>
>>>>>>> I think, I am missing something in configuration. Can I use LDAP
>>>>>>> without
>>>>>>>
>>>>>>> sasl and if yes, what I need to do?
>>>>>>>
>>>>>>>> You can, but it's not recommended. Try putting this line in
>>>>>>>> slapd.conf:
>>>>>>>>
>>>>>>>> allow bind_v2 bind_anon_cred bind_anon_dn
>>>>>>>
>>>>>>> Oh, and by the way, we prefer bottom posting on the list.
>>>>>>>
>>>>>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens <ricks at nerd.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Nilesh Joshi wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>> I have installed openldap-2.0.27-23 on my server.
>>>>>>>>>
>>>>>>>>>> I have configured certificate and path is mentioned in slapd.conf
>>>>>>>>>> file.
>>>>>>>>>>
>>>>>>>>>> I am able to create root DN and also able to add user to it.
>>>>>>>>>>
>>>>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct
>>>>>>>>>> answers.
>>>>>>>>>> Howere, whenever I search using user id, I see error 49.
>>>>>>>>>>
>>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D
>>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)'
>>>>>>>>>>
>>>>>>>>>> In logs, I see:
>>>>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389)
>>>>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com"
>>>>>>>>>> method=128
>>>>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text=
>>>>>>>>>> conn=11 fd=10 closed (connection lost)
>>>>>>>>>>
>>>>>>>>>> I would like to have openldap running without sasl.
>>>>>>>>>>
>>>>>>>>>> How should I configure the same? How can I fix this issue?
>>>>>>>>>>
>>>>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand
>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>> ldapsearch the right password for the user you're trying to bind
>>>>>>>>>> as.
>>>>>>>>>>
>>>>>>>>> Try it again, but rather than using the "-W" (interactive) flag,
>>>>>>>>> try:
>>>>>>>>>
>>>>>>>>> -w 'your-password-here'
>>>>>>>>>
>>>>>>>>> If the password has shell metacharacters in it, they may be being
>>>>>>>>> interpreted by the shell before being handed to the ldapsearch
>>>>>>>>> command.
>>>>>>>>> Using the -w and the password enclosed in single quotes prevents
>>>>>>>>> that.
>>>>>>>>>
>>>>>>>>> You also have to make sure that the user you're trying to bind as
>>>>>>>>> has
>>>>>>>>> access to the userPassword attribute in the slapd.conf file:
>>>>>>>>>
>>>>>>>>> access to attrs=userPassword
>>>>>>>>> by anonymous auth
>>>>>>>>> by self write
>>>>>>>>> by * none
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>> - Rick Stevens, Systems Engineer
>>>>>>>>> ricks at nerd.com-
>>>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo:
>>>>>>>>> origrps2
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> -
>>>>>>>>> - I never drink water because of the disgusting things that fish do
>>>>>>>>> -
>>>>>>>>> - in it.
>>>>>>>>> -
>>>>>>>>> - -- WC.
>>>>>>>>> Fields
>>>>>>>>> -
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ----------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Redhat-install-list mailing list
>>>>>>>>> Redhat-install-list at redhat.com
>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>>>> redhat-install-list-request at redhat.com
>>>>>>>>> Subject: unsubscribe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Redhat-install-list mailing list
>>>>>>>> Redhat-install-list at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>>> redhat-install-list-request at redhat.com
>>>>>>>> Subject: unsubscribe
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com-
>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2
>>>>>>> -
>>>>>>> -
>>>>>>> -
>>>>>>> - Never test for an error condition you don't know how to handle.
>>>>>>> -
>>>>>>>
>>>>>>>
>>>>>>> ----------------------------------------------------------------------
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Redhat-install-list mailing list
>>>>>>> Redhat-install-list at redhat.com
>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>>> redhat-install-list-request at redhat.com
>>>>>>> Subject: unsubscribe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>> _______________________________________________
>>>>>> Redhat-install-list mailing list
>>>>>> Redhat-install-list at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>>> redhat-install-list-request at redhat.com
>>>>>> Subject: unsubscribe
>>>>>>
>>>>>>
>>>>>> --
>>>>> ----------------------------------------------------------------------
>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com -
>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
>>>>> - -
>>>>> - Brain: The organ with which we think that we think. -
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Redhat-install-list mailing list
>>>>> Redhat-install-list at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>>> redhat-install-list-request at redhat.com
>>>>> Subject: unsubscribe
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Redhat-install-list mailing list
>>>> Redhat-install-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>>> redhat-install-list-request at redhat.com
>>>> Subject: unsubscribe
>>>>
>>>>
>>> --
>>> ----------------------------------------------------------------------
>>> - Rick Stevens, Systems Engineer ricks at nerd.com -
>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
>>> - -
>>> - Do you know where _your_ towel is? -
>>>
>>> ----------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Redhat-install-list mailing list
>>> Redhat-install-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>>> To Unsubscribe Go To ABOVE URL or send a message to:
>>> redhat-install-list-request at redhat.com
>>> Subject: unsubscribe
>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Redhat-install-list mailing list
>> Redhat-install-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/redhat-install-list
>> To Unsubscribe Go To ABOVE URL or send a message to:
>> redhat-install-list-request at redhat.com
>> Subject: unsubscribe
>>
>
>
> --
> ----------------------------------------------------------------------
> - Rick Stevens, Systems Engineer ricks at nerd.com -
> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
> - -
> - What is a "free" gift? Aren't all gifts free? -
>
> ----------------------------------------------------------------------
>
> _______________________________________________
> Redhat-install-list mailing list
> Redhat-install-list at redhat.com
> https://www.redhat.com/mailman/listinfo/redhat-install-list
> To Unsubscribe Go To ABOVE URL or send a message to:
> redhat-install-list-request at redhat.com
> Subject: unsubscribe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/redhat-install-list/attachments/20090818/910e0b29/attachment.htm>
More information about the Redhat-install-list
mailing list