A bug in a PHP scripthttp://www.linuxquestions.org/questions/showthread.php?p=4813771 has caused some entries in the LDAP databasehttp://www.linuxquestions.org/questions/showthread.php?p=4813771 to have invalid values:
# James + Bond, people, mi6.gov.uk dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk sn: Bond givenName: James cn:: U3RldmUg gecos:: U3RldmUg
As you can see, the cn: and gecos: have the invalid values - they should be James Bond.
I did attempt to correct the problem with ldapmodify by putting the following into a file called updateCN.ldif:
dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk changetype:modify replace: cn cn: James Bond
and executing the following command:
ldapmodify -x -W -D "cn=admin,dc=mi6,dc=gov,dc=uk" -f updateCN.ldif
This returned the following error
Enter LDAP Password: modifying entry "cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk" ldap_modify: Naming violation (64) additional info: value of naming attribute 'cn' is not present in entry
I have also tried ldapmodrdn:
ldapmodrdn -r -f updateCN.ldif
with updateCN.ldif:
dn: cn=James Bond+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk cn=James Bond
$ ldapmodrdn -r -f updateCN.ldif SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
and
ldapmodify -f updateCN.ldif
with updateCN.ldif:
dn: cn=James Bond+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk changetype: modrdn newrdn: cn=James Bond deleteoldrdn: 1
$ ldapmodify -f updateCN.ldif SASL/DIGEST-MD5 authentication started Please enter your password: ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80) additional info: SASL(-13): user not found: no secret in database
How can I correct the invalid values in the LDAP database? THINK BEFORE YOU PRINT======================================================================
The information contained in this email is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. YOU MUST NOT use, disclose, copy or alter this message for any unauthorized purpose. Neither Electricity North West Limited nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.
Electricity North West Limited 304 Bridgewater Place, Birchwood Park Warrington WA3 6XG, Registered in England and Wales Registration No 02366949 ===========================================================================================
29.10.2012 14:59, Whiteman, Craig пишет:
# James + Bond, people, mi6.gov.uk dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk sn: Bond givenName: James cn:: U3RldmUg gecos:: U3RldmUg
As you can see, the *cn:* and *gecos:* have the invalid values - they should be *James Bond*.
How can I correct the invalid values in the LDAP database?
That is rather strange bug (perhaps mental one), because there is no "James", not a "Bond" but there is a "Steve", hm... echo U3RldmUg|base64 -d Steve May I look at the entire database? :)
Actually cn and gecos have correct values, but encoded.
I did change the names in the example to try to protect the actual names - we don’t really have a James Bond working for the company!
The actual entry in LDAP did come from somebody called Steve - it was quite incisive of you to discover it had been base64 encoded. Unfortunately the PHP script was not supposed to encode the value - the cn: and gecos: should contain the unencoded value James Bond as this will match the format of all of the other valid entries in the database. I did attempt to correct the value with ldapmodify but was unsuccessful.
-----Original Message----- From: openldap-technical-bounces@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Roman Rybalko Sent: 29 October 2012 11:34 Cc: OpenLDAP Technical List Subject: Re: OpenLDAP - how to correct invalid cn values
29.10.2012 14:59, Whiteman, Craig пишет:
# James + Bond, people, mi6.gov.uk dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk sn: Bond givenName: James cn:: U3RldmUg gecos:: U3RldmUg
As you can see, the *cn:* and *gecos:* have the invalid values - they should be *James Bond*.
How can I correct the invalid values in the LDAP database?
That is rather strange bug (perhaps mental one), because there is no "James", not a "Bond" but there is a "Steve", hm... echo U3RldmUg|base64 -d Steve May I look at the entire database? :)
Actually cn and gecos have correct values, but encoded. -- WBR, Roman Rybalko
THINK BEFORE YOU PRINT======================================================================
The information contained in this email is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. YOU MUST NOT use, disclose, copy or alter this message for any unauthorized purpose. Neither Electricity North West Limited nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.
Electricity North West Limited 304 Bridgewater Place, Birchwood Park Warrington WA3 6XG, Registered in England and Wales Registration No 02366949 ===========================================================================================
Craig,
Whiteman, Craig schrieb (29.10.2012 11:59 Uhr):
A bug in a PHP script http://www.linuxquestions.org/questions/showthread.php?p=4813771 has caused some entries in the LDAP database http://www.linuxquestions.org/questions/showthread.php?p=4813771 to have invalid values:
by "invalid" you mean "not what I want" and not "technically invalid", right?
# James + Bond, people, mi6.gov.uk dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk sn: Bond givenName: James cn:: U3RldmUg gecos:: U3RldmUg
Technically this is all fine, except that - as Roman pointed out - you did not craft your example well by not changing encodes "Steve" to "James".
As you can see, the *cn:* and *gecos:* have the invalid values - they should be *James Bond*.
They are not invalid, they are encoded, but this is fine.
I did attempt to correct the problem with ldapmodify by putting the following into a file called updateCN.ldif:
dn: cn=James+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk changetype:modify replace: cn cn: James Bond
Please learn more about LDAP in general and about DN and RDN. cn is part of your RDN, so the CN value in your RDN must be in your object. By trying to replace the cn, this is not true anymore.
It does not make thing easier that you have a RDN combined from two attributes.
I have also tried ldapmodrdn: ldapmodrdn -r -f updateCN.ldif with updateCN.ldif:
dn: cn=James Bond+sn=Bond,ou=people,dc=mi6,dc=gov,dc=uk cn=James Bond
$ ldapmodrdn -r -f updateCN.ldif
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-13): user not found: no secret in database
please read "man ldapmodrdn".
Marc
30.10.2012 12:41, Whiteman, Craig пишет:
I did change the names in the example to try to protect the actual names - we don’t really have a James Bond working for the company!
The actual entry in LDAP did come from somebody called Steve - it was quite incisive of you to discover it had been base64 encoded. Unfortunately the PHP script was not supposed to encode the value - the cn: and gecos: should contain the unencoded value James Bond as this will match the format of all of the other valid entries in the database. I did attempt to correct the value with ldapmodify but was unsuccessful.
That was stupid joke of mine, Sorry, shame on me.
Attribute encoding is done by client code only (gurus, correct me please if I'm not right). Perhaps php script also does encode attributes. You probably did try to change actually correct values with the same (you thought more correct) values, but the server refused to do this because it was supposed to do nothing. You may try different ldap clients to make sure you see the data correctly.
openldap-technical@openldap.org
-
Marc Patermann -
Roman Rybalko -
Whiteman, Craig