<quote who="Naufal Sheikh">
Vi ...
Come on, what sort of answer is that? How can we possibly help if you don't provide concrete information.
What command do you type to make the modification?
ldapmodify?
What were the exact arguments?
On 10/30/07, Gavin Henry ghenry@suretecsystems.com wrote:
<quote who="Naufal Sheikh"> > Hello Piotr, > > I tried to do what you said. Initially my root dn just contained > cn=nsadmin, > and thus I caould not start slapd. Then I added to rootdn my suffix as > well, > and unhashed the rootpw line in slapd.conf. I tried using a clear text > "secret" as well as hashed value created through slappasswd and putting it > in the slapd.conf. In both cases, when I modify the entry and it asks me > to > give ldap password, it says invalid credentials.
How are you trying to modify? What tool?
I am sorry if I am not able to provide the exact information. What I meant was that I am using VI editor to modify the slapd.conf file. Here is exactly what I have done:
I compiled and installed openldap version 2.2.20 on red hat Linux 8.0. I did everything according to the manual and was able to install the software successfully. The only catch being that I was never asked to supply any password during the installation, which some of the posts in the mailing list suggested.
I have a running version of 2.2.20 on Solaris 8.0.
I first copied all of the slapd.conf from solaris server file to my red hat server, but the slapd gave errors and was not able to start initially.
I then started copying the slapd.conf from my production to new server bit by bit, adding few lines and then checking if I can start the slapd or not, and eventually I had exact replica of the slapd.conf file on my red hat server and slapd was starting without any errors.
I then used slapcat on my production system to generate an ldif which I imported on red hat server using slapadd. I had few errors about the syntax of "clientOrg" attribute being not correct, but those entries contained the extended character set in their values and I deleted them from the ldif file till I was able to import all the ldif from the production system to red hat server.
Now the slapd was running perfectly and I could bind anonymously to my ldap server on the red hat and it was fetching all the entries correctly.
The problem started when i try to bind to ldap using the credentials which were used on the production system. The slapd.conf file on the production system had the "rootpw secret" line hashed. When I unhashed it, slap did not start stating that rootdn should be under the suffix. While it was not on the production server, I added to my rootdn my suffix as well, and slapd started perfectly. Now as Piotr suggested that after creating a password I can hash the rootpw line again, so that the authentication can be done using only the passwords in the database. So using slappasswd i generated a hash value of the password and copied it into the slapd.conf. While slapd starts fine it still cannot connect to ldap using the supplied credentials saying invalid credentials. Same happens if I try to modify any uid using slapmodify it asks for an ldap password and when I give the password which i pasted in my slapd.conf it says invalid credentials.
Hope this is a more clearer explanation. Please let me know if you want to have a look at my slapd.conf file or anything else.
This is the only point where I am stuck, rest is fine. Thank you so much for your help.
P.S the command I use to modfy the entries in the database is:
ldapmodify -v -x -f /path-to-ldif -w -D "cn=nsadmin,o=trac"
Thanks and Regards
On 10/30/07, Gavin Henry ghenry@suretecsystems.com wrote:
<quote who="Naufal Sheikh"> > Vi ...
Come on, what sort of answer is that? How can we possibly help if you don't provide concrete information.
What command do you type to make the modification?
ldapmodify?
What were the exact arguments?
On 10/30/07, Gavin Henry ghenry@suretecsystems.com wrote:
<quote who="Naufal Sheikh"> > Hello Piotr, > > I tried to do what you said. Initially my root dn just contained > cn=nsadmin, > and thus I caould not start slapd. Then I added to rootdn my suffix
as
well, and unhashed the rootpw line in slapd.conf. I tried using a clear
text
"secret" as well as hashed value created through slappasswd and
putting it
in the slapd.conf. In both cases, when I modify the entry and it asks
me
to give ldap password, it says invalid credentials.
How are you trying to modify? What tool?
Naufal Sheikh wrote:
I compiled and installed openldap version 2.2.20
Why the hell are you using such an ancient version?
If you're already building yourself why didn't you use recent stable version 2.3.3x?
The only catch being that I was never asked to supply any password during the installation,
It does not work like that.
which some of the posts in the mailing list suggested.
I doubt that anyone here claimed that 'make install' asks for a password.
I have a running version of 2.2.20 on Solaris 8.0.
So watch out for rootdn and rootpw in the file slapd.conf.
I first copied all of the slapd.conf from solaris server file to my red hat server, but the slapd gave errors and was not able to start initially.
If you don't provide the exact error message noone will be able to help.
I then used slapcat on my production system to generate an ldif which I imported on red hat server using slapadd. I had few errors about the syntax of "clientOrg" attribute being not correct, but those entries contained the extended character set in their values and I deleted them from the ldif file till I was able to import all the ldif from the production system to red hat server.
Do you really know what you're doing? I bet "clientOrg" is a custom schema. Who defined that? Isn't the data therein important for you?
Now as Piotr suggested that after creating a password I can hash the rootpw line again, so that the authentication can be done using only the passwords in the database. So using slappasswd i generated a hash value of the password and copied it into the slapd.conf. While slapd starts fine it still cannot connect to ldap using the supplied credentials saying invalid credentials.
Does your LDIF contain an entry with attribute "userPassword" for the "rootdn" in slapd.conf? Maybe try changing rootdn in slapd.conf to something else and try with that one.
Ciao, Michael.
ldapmodify -v -x -f /path-to-ldif -w -D "cn=nsadmin,o=trac"
When you try to modify ldap entry, using ldif file, how do you add "userPassword" field ? In ldif file usually hashed password value, e.g.
if you have password "foobar", hashed {CRYPT} string will be $1$J/E/qSv7$SQtxGHJ2UTwkQ40qX8WcN/ Now, with some gui tool like GQ or LdapStudio, you should add prefix {CRYPT} and paste
{CRYPT}$1$J/E/qSv7$SQtxGHJ2UTwkQ40qX8WcN/
into ldap object. This should also work, if you paste above string with {CRYPT} prefix (or {MD5} or other, depending how you hashed the password.
Note that with slapcat/slapadd user password should be additionaly base64 encoded, and AFAIR, "userPassword" attribute name should be prepended with double colon, e.g
perl -MMIME::Base64 -e "print encode_base64('{CRYPT}$1$J/E/qSv7$SQtxGHJ2UTwkQ40qX8WcN/');"
userPassword:: e0NSWVBUfS9FL3FTdjcv
Anyway does authentication work with slapd.conf including plain or hashed password? P.
The passowrd is hashed in the ldif file which I am importing from the production system, as below:
# id=00000003 dn: uid=nsadmin,o=trac objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: SuiteSpot Administrator sn: Administrator givenName: SuiteSpot uid: nsadmin creatorsName: cn=nsadmin createTimestamp: 19980218204619Z userPassword:: e1NIQX12bm4rOFpBNFNzdzJJMnlQOVZ2clBJVFlGRzg9 modifiersName: uid=nsadmin,o=trac modifyTimestamp: 19980722182149Z structuralObjectClass: inetOrgPerson entryUUID: 8179b9a2-74d7-102a-9988-90f8caf384a9 entryCSN: 20060511011623Z#000003#00#000000
While putting in the same in slapd.conf wither in hashed form or plain text, it always say invalid credentials.
On 10/30/07, Piotr Wadas pwadas@jewish.org.pl wrote:
ldapmodify -v -x -f /path-to-ldif -w -D "cn=nsadmin,o=trac"
When you try to modify ldap entry, using ldif file, how do you add "userPassword" field ? In ldif file usually hashed password value, e.g.
if you have password "foobar", hashed {CRYPT} string will be $1$J/E/qSv7$SQtxGHJ2UTwkQ40qX8WcN/ Now, with some gui tool like GQ or LdapStudio, you should add prefix {CRYPT} and paste
{CRYPT}$1$J/E/qSv7$SQtxGHJ2UTwkQ40qX8WcN/
into ldap object. This should also work, if you paste above string with {CRYPT} prefix (or {MD5} or other, depending how you hashed the password.
Note that with slapcat/slapadd user password should be additionaly base64 encoded, and AFAIR, "userPassword" attribute name should be prepended with double colon, e.g
perl -MMIME::Base64 -e "print encode_base64('{CRYPT}$1$J/E/qSv7$SQtxGHJ2UTwkQ40qX8WcN/');"
userPassword:: e0NSWVBUfS9FL3FTdjcv
Anyway does authentication work with slapd.conf including plain or hashed password? P.
The passowrd is hashed in the ldif file which I am importing from the production system, as below:
# id=00000003 dn: uid=nsadmin,o=trac objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: SuiteSpot Administrator sn: Administrator givenName: SuiteSpot uid: nsadmin creatorsName: cn=nsadmin createTimestamp: 19980218204619Z userPassword:: e1NIQX12bm4rOFpBNFNzdzJJMnlQOVZ2clBJVFlGRzg9 modifiersName: uid=nsadmin,o=trac modifyTimestamp: 19980722182149Z structuralObjectClass: inetOrgPerson entryUUID: 8179b9a2-74d7-102a-9988-90f8caf384a9 entryCSN: 20060511011623Z#000003#00#000000
This is not modify operation ldap file. Modify operation ldif file should look like this: (in example two values of userPassword will be added to "cn=admin,dc=foo" object, and all old values of userPassword attribute will be removed.
dn: cn=admin,dc=foo changetype: modify replace: userPassword userPassword: {CRYPT}hashpasswordvaluehere userPassword: {MD5}passwordhashedinotherway
Regards, Piotr
yeah this is the main ldif file which I initilly imported. oh ok.... you want me to change the password of nsadmin by making an ldif file loike above, Yes the paswords were not in the hashed form in the modify operation. Ok I will try doing this, as soon as I get my database up.
Regards
On 10/30/07, Piotr Wadas pwadas@jewish.org.pl wrote:
The passowrd is hashed in the ldif file which I am importing from the production system, as below:
# id=00000003 dn: uid=nsadmin,o=trac objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: SuiteSpot Administrator sn: Administrator givenName: SuiteSpot uid: nsadmin creatorsName: cn=nsadmin createTimestamp: 19980218204619Z userPassword:: e1NIQX12bm4rOFpBNFNzdzJJMnlQOVZ2clBJVFlGRzg9 modifiersName: uid=nsadmin,o=trac modifyTimestamp: 19980722182149Z structuralObjectClass: inetOrgPerson entryUUID: 8179b9a2-74d7-102a-9988-90f8caf384a9 entryCSN: 20060511011623Z#000003#00#000000
This is not modify operation ldap file. Modify operation ldif file should look like this: (in example two values of userPassword will be added to "cn=admin,dc=foo" object, and all old values of userPassword attribute will be removed.
dn: cn=admin,dc=foo changetype: modify replace: userPassword userPassword: {CRYPT}hashpasswordvaluehere userPassword: {MD5}passwordhashedinotherway
Regards, Piotr
Hi Piotr,
Here is my ldif file.
dn: cn=nsadmin changetype: modify userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= and the command I used is:
[root@syru156 bin]# ./ldapmodify -x -v -f /main/backup/nsadmin.ldif ldap_initialize( <DEFAULT> ) replace userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= modifying entry "cn=nsadmin" modify complete ldap_modify: Strong(er) authentication required (8) additional info: modifications require authentication
and I cannot still connect bind to ldap through credentials. It says invalid credentials when I try to connect it through ldap browser.
Regards
On 10/30/07, Naufal Sheikh naufalzamir@gmail.com wrote:
yeah this is the main ldif file which I initilly imported. oh ok.... you want me to change the password of nsadmin by making an ldif file loike above, Yes the paswords were not in the hashed form in the modify operation. Ok I will try doing this, as soon as I get my database up.
Regards
On 10/30/07, Piotr Wadas pwadas@jewish.org.pl wrote:
The passowrd is hashed in the ldif file which I am importing from the production system, as below:
# id=00000003 dn: uid=nsadmin,o=trac objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: SuiteSpot Administrator sn: Administrator givenName: SuiteSpot uid: nsadmin creatorsName: cn=nsadmin createTimestamp: 19980218204619Z userPassword:: e1NIQX12bm4rOFpBNFNzdzJJMnlQOVZ2clBJVFlGRzg9 modifiersName: uid=nsadmin,o=trac modifyTimestamp: 19980722182149Z structuralObjectClass: inetOrgPerson entryUUID: 8179b9a2-74d7-102a-9988-90f8caf384a9 entryCSN: 20060511011623Z#000003#00#000000
This is not modify operation ldap file. Modify operation ldif file should look like this: (in example two values of userPassword will be added to "cn=admin,dc=foo" object, and all old values of userPassword attribute will be removed.
dn: cn=admin,dc=foo changetype: modify replace: userPassword userPassword: {CRYPT}hashpasswordvaluehere userPassword: {MD5}passwordhashedinotherway
Regards, Piotr
On Tue, 30 Oct 2007, Naufal Sheikh wrote:
Hi Piotr,
Here is my ldif file.
dn: cn=nsadmin changetype: modify userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= and the command I used is:
[root@syru156 bin]# ./ldapmodify -x -v -f /main/backup/nsadmin.ldif ldap_initialize( <DEFAULT> ) replace userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= modifying entry "cn=nsadmin" modify complete ldap_modify: Strong(er) authentication required (8) additional info: modifications require authentication
and I cannot still connect bind to ldap through credentials. It says invalid credentials when I try to connect it through ldap browser.
Regards
instead, try:
cat modify-pass.ldif | ldapmodify -vcxWh localhost -D "cn=admin,dc=foo"
and type-in password you've put into rootpw in slapd.conf, when asked.
You should really look into ldapmodify manpage, and admin guide :)
Regards, Piotr
Ezzel a dátummal: Tuesday 30 October 2007 21.54.49 Naufal Sheikh ezt írta:
Hi Piotr,
Here is my ldif file.
dn: cn=nsadmin changetype: modify userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= and the command I used is:
[root@syru156 bin]# ./ldapmodify -x -v -f /main/backup/nsadmin.ldif ldap_initialize( <DEFAULT> ) replace userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= modifying entry "cn=nsadmin" modify complete ldap_modify: Strong(er) authentication required (8) additional info: modifications require authentication
and I cannot still connect bind to ldap through credentials. It says invalid credentials when I try to connect it through ldap browser.
You didn't specify what DN you want to connect. "Use ldapmodify -D cn=nsadmin,o=trac -x ...". And use the password you gave in slapd.conf. The "rootdn" and "rootpw" have precedence over the one you have in the directory.
Bye, György
Hello,
Well Finally I have got something. I have one last question though, regarding the concept, Below is the excerpt from my new slapd.conf:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin,o=trac"
rootpw plain-text password.
When I write cn=nsadmin,o=trac in userDN box in ldap brwoser and give the password given in the plain text in slapd.conf it connects to the ldap server using the credentials.
While in my old slapd.conf file which I was using as a reference the rootpw line is hashed and in rootdn it is only :cn-nsadmin" as follows:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin"
#rootpw secret.
Rest both the configuration files are same. But on the old server I can still connect the ldap server through ldap browser using UserDn cn=nsadmin and the password. My question is how is that happening? I have not really grasped this idea.
Also nsadmin exists as a user and I can see that it has a hashed password on my original server, while on my new server since (probably i did not used hashed password in slapd.conf) it appears as the plain text. If any one can please point me to the right section of the guide to understand or tell me in simple words!
Thank you all for your help despite of vague questions and replies.
Regards
On 10/31/07, Szombathelyi György gyurco@freemail.hu wrote:
Ezzel a dátummal: Tuesday 30 October 2007 21.54.49 Naufal Sheikh ezt írta:
Hi Piotr,
Here is my ldif file.
dn: cn=nsadmin changetype: modify userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= and the command I used is:
[root@syru156 bin]# ./ldapmodify -x -v -f /main/backup/nsadmin.ldif ldap_initialize( <DEFAULT> ) replace userpassword: {SHA}R0f182La8UTJewHKUWIr2ltHPXc= modifying entry "cn=nsadmin" modify complete ldap_modify: Strong(er) authentication required (8) additional info: modifications require authentication
and I cannot still connect bind to ldap through credentials. It says invalid credentials when I try to connect it through ldap browser.
You didn't specify what DN you want to connect. "Use ldapmodify -D cn=nsadmin,o=trac -x ...". And use the password you gave in slapd.conf. The "rootdn" and "rootpw" have precedence over the one you have in the directory.
Bye, György
On Thursday 01 November 2007 18:59:56 Naufal Sheikh wrote:
Hello,
Well Finally I have got something. I have one last question though, regarding the concept, Below is the excerpt from my new slapd.conf:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin,o=trac"
rootpw plain-text password.
When I write cn=nsadmin,o=trac in userDN box in ldap brwoser and give the password given in the plain text in slapd.conf it connects to the ldap server using the credentials.
While in my old slapd.conf file which I was using as a reference the rootpw line is hashed and in rootdn it is only :cn-nsadmin" as follows:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin"
#rootpw secret.
Rest both the configuration files are same. But on the old server I can still connect the ldap server through ldap browser using UserDn cn=nsadmin and the password. My question is how is that happening?
The DN exists in the directory (under a different suffix/database?), and the password is set on the DN, in which case (since rootpw is commented out), the DN is authenticated against the in-directory password.
I have not really grasped this idea.
Also nsadmin exists as a user
entry in LDAP.
and I can see that it has a hashed password on my original server,
In the directory
while on my new server since (probably i did not used hashed password in slapd.conf) it appears as the plain text.
But you can use an encrypted password, see the slappasswd command.
If any one can please point me to the right section of the guide to understand or tell me in simple words!
Thank you all for your help despite of vague questions and replies.
Regards, Buchan
Thank you so very much... That was it..... there was this another database defined at the end, which just said suffix="" (I am not sure what it meant, however, using slap cat I gave -b "" and then added it via slapadd again giving -b="" and it worked. after hashing the rootpw defined in the first database.
On 11/2/07, Buchan Milne bgmilne@staff.telkomsa.net wrote:
On Thursday 01 November 2007 18:59:56 Naufal Sheikh wrote:
Hello,
Well Finally I have got something. I have one last question though, regarding the concept, Below is the excerpt from my new slapd.conf:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin,o=trac"
rootpw plain-text password.
When I write cn=nsadmin,o=trac in userDN box in ldap brwoser and give
the
password given in the plain text in slapd.conf it connects to the ldap server using the credentials.
While in my old slapd.conf file which I was using as a reference the
rootpw
line is hashed and in rootdn it is only :cn-nsadmin" as follows:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin"
#rootpw secret.
Rest both the configuration files are same. But on the old server I can still connect the ldap server through ldap browser using UserDn
cn=nsadmin
and the password. My question is how is that happening?
The DN exists in the directory (under a different suffix/database?), and the password is set on the DN, in which case (since rootpw is commented out), the DN is authenticated against the in-directory password.
I have not really grasped this idea.
Also nsadmin exists as a user
entry in LDAP.
and I can see that it has a hashed password on my original server,
In the directory
while on my new server since (probably i did not used hashed password in slapd.conf) it appears as the plain text.
But you can use an encrypted password, see the slappasswd command.
If any one can please point me to the right section of the guide to understand
or
tell me in simple words!
Thank you all for your help despite of vague questions and replies.
Regards, Buchan
Naufal Sheikh wrote:
Hello,
Well Finally I have got something. I have one last question though, regarding the concept, Below is the excerpt from my new slapd.conf:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin,o=trac"
rootpw plain-text password.
When I write cn=nsadmin,o=trac in userDN box in ldap brwoser and give the password given in the plain text in slapd.conf it connects to the ldap server using the credentials.
While in my old slapd.conf file which I was using as a reference the rootpw line is hashed and in rootdn it is only :cn-nsadmin" as follows:
backend bdb
database monitor
database bdb suffix "o=trac" rootdn "cn=nsadmin"
#rootpw secret.
Rest both the configuration files are same. But on the old server I can still connect the ldap server through ldap browser using UserDn cn=nsadmin and the password. My question is how is that happening? I have not really grasped this idea.
It lets you connect because that's what you have written in the rootdn field.
Also nsadmin exists as a user and I can see that it has a hashed password on my original server, while on my new server since (probably i did not used hashed password in slapd.conf) it appears as the plain text. If any one can please point me to the right section of the guide to understand or tell me in simple words!
You probably mean you see base64 encoding.
Thank you all for your help despite of vague questions and replies.
Regards
On Tuesday 30 October 2007 21:49:31 Naufal Sheikh wrote:
The passowrd is hashed in the ldif file which I am importing from the production system, as below:
# id=00000003 dn: uid=nsadmin,o=trac objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: SuiteSpot Administrator sn: Administrator givenName: SuiteSpot uid: nsadmin creatorsName: cn=nsadmin createTimestamp: 19980218204619Z userPassword:: e1NIQX12bm4rOFpBNFNzdzJJMnlQOVZ2clBJVFlGRzg9
If you had added the base64-decoded version of this password, which looks like this:
{SHA}vnn+8ZA4Ssw2I2yP9VvrPITYFG8=
to slapd.conf after the rootpw keyword, then things should have worked ...
Regards, Buchan
openldap-software@openldap.org
-
Buchan Milne -
Gavin Henry -
Gavin Henry -
Michael Ströder -
Naufal Sheikh -
Piotr Wadas -
Szombathelyi György