openldap-technical

openldap-technical@openldap.org

1 participants
9868 discussions

Data validation
by bob＠swin.edu.au 12 Mar '13

12 Mar '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Can anyone point me to a means of performing some sort of data validation on input data at the server end? Specifically, I want to store email addresses to be looked up by sendmail when doing alias processing. I want to have these aliases managed by users who may not be totally trustworthy, so I'd like to knock out any attempts to add aliases that have redirection or pipe operators in them. The printable string schema syntax (OID=1.3.6.1.4.1.1466.115.121.1.44) is pretty close to what I need, but it doesn't include the '@' character. Any ideas? Thanks in advance, Bob..... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (MingW32) Comment: No comment iD8DBQFRPneLpjfLzfdVw6YRAjueAKCV7fVyve4m0wTNy0S4/FNMrdT2XACcCryX Sn7CpG8ZHVVlUn+mu9kLE00= =nql5 -----END PGP SIGNATURE-----

2 1

S/Mime configuration
by Jignesh Patel 12 Mar '13

12 Mar '13

How to configure s/mime with openldap 2.4.23? -Jignesh

3 7

shadowLastChange missing after update
by Maria McKinley 11 Mar '13

11 Mar '13

Hi there, I recently changed from the slapd.conf configuration to the slapd.d configuration. Everything seemed to go reasonably well, but for some reason the shadowLastChange attribute was missing from all of the people. When I try to add it back in, I get: ldap_add: Object class violation (65) additional info: no objectClass attribute but, I seem to have the schema and objectClasses for ShadowLastChange: annette:~# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=schema,cn=config "(objectClass=olcSchemaConfig)" dn dn: cn=schema,cn=config dn: cn={0}core,cn=schema,cn=config dn: cn={1}cosine,cn=schema,cn=config dn: cn={2}nis,cn=schema,cn=config dn: cn={3}inetorgperson,cn=schema,cn=config dn: cn={4}misc,cn=schema,cn=config maria@mimi:~/sysadmin$ ldapsearch -xLLL "uid=jd" dn: uid=jd,ou=people,dc=example,dc=com objectClass: top objectClass: posixAccount objectClass: shadowAccount objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient cn: Jochen Ditterich shadowMax: 365 gidNumber: 100 uid: jd homeDirectory: /home/jd mailRoutingAddress: jd(a)example.com uidNumber: 1025 sn: Ditterich shadowWarning: 7 mailLocalAddress: jd mail: jd(a)example.com loginShell: /bin/bash Anyone have any idea what might be going on? What am I missing? thanks, maria

3 5

Import base64 info
by arantza serrano 11 Mar '13

11 Mar '13

Hello, I’m trying to import my LDIF where some attributes are in base64: /opt/openldap/bin/ldapadd -x -D "root_dn" -w pass_dn << _EOF dn: uid=usu3,ou=users,o=my_organization uid: usu2 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson cn:: Q0FNSdFBCg== sn: my_sn mail: my_mail(a)mydomain.com userPassword: usuario > _EOF Then I get this error: adding new entry " uid=usu3,ou=users,o=my_organization " ldap_add: Invalid syntax (21) additional info: cn: value #0 invalid per syntax If I decode the value, I get the same error: /opt/openldap/bin/ldapadd -x -D "root_dn" -w pass_dn << _EOF dn: uid=usu3,ou=users,o=my_organization uid: usu2 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson cn: CAMIÑA sn: my_sn mail: my_mail(a)mydomain.com userPassword: usuario _EOF adding new entry " uid=usu3,ou=users,o=my_organization " ldap_add: Invalid syntax (21) additional info: cn: value #0 invalid per syntax How can I import my LDIF? Thanks!

5 5

Re: Import base64 info
by Jorge.armijo 11 Mar '13

11 Mar '13

elimina el caracter especial y prueb asi ese problema tenia yo usa la herramienta grafica ldapexplorer Enviado desde Samsung Mobile arantza serrano <zazu2276(a)hotmail.com> escribió: Hello, I’m trying to import my LDIF where some attributes are in base64: /opt/openldap/bin/ldapadd -x -D "root_dn" -w pass_dn << _EOF dn: uid=usu3,ou=users,o=my_organization uid: usu2 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson cn:: Q0FNSdFBCg== sn: my_sn mail: my_mail(a)mydomain.com userPassword: usuario > _EOF Then I get this error: adding new entry " uid=usu3,ou=users,o=my_organization " ldap_add: Invalid syntax (21) additional info: cn: value #0 invalid per syntax If I decode the value, I get the same error: /opt/openldap/bin/ldapadd -x -D "root_dn" -w pass_dn << _EOF dn: uid=usu3,ou=users,o=my_organization uid: usu2 objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson cn: CAMIÑA sn: my_sn mail: my_mail(a)mydomain.com userPassword: usuario _EOF adding new entry " uid=usu3,ou=users,o=my_organization " ldap_add: Invalid syntax (21) additional info: cn: value #0 invalid per syntax How can I import my LDIF? Thanks!

1 0

ldap start and stop scripts
by francesco.policastro＠selex-es.com 11 Mar '13

11 Mar '13

Hi, Can anyone address me to a script to start and stop openldap? I mean a script to use with chkconfig. What I found online is somehow obsolete, i.e. it refers to slurpd and slapd.conf, with no reference to slapd.d I installed rev. 2.4.33 from sources. Thanks in advance, Francesco

3 4

getent passwd inconsistent loginShell with ldapsearch
by Rodney Simioni 08 Mar '13

08 Mar '13

Hi, When I do a 'getent check72 passwd' I get: check72:*:6072:6072:Johnny Appleseed:/home/check72:/bin/bash But when I do a ldapsearch command I get: # check72, people, wh.local dn: uid=check72,ou=people,dc=wh,dc=local uid: check72 cn: Johnny Appleseed objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount userPassword:: e1NTSEF9OWVHdTdPVHIwVE15ajNQNEphdG9GR1cwZnQxa2Ftb3k= shadowLastChange: 15140 shadowMax: 99999 shadowWarning: 7 uidNumber: 6072 gidNumber: 6072 homeDirectory: /home/check72 loginShell: /bin/noshell # check72, group, wh.local dn: cn=check72,ou=group,dc=wh,dc=local objectClass: posixGroup objectClass: top cn: check72 gidNumber: 6072 userPassword:: e0NSWVBUfXg= # search result search: 2 result: 0 Success I have rstarted slapd and nscd, any clue? Thanks in advance. This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you.

2 3

SASL/PLAIN Passthrough auth
by Robin Helgelin 08 Mar '13

08 Mar '13

Hi, I have a SASL pass-through authentication working when using a simple bind only on users that has a userPassword starting with {SASL}. When the users password contains {SASL}extraAuthInformation, the extraAuthInformation is passed on as username to the saslauthd and everything works as it should. However, when using SASL/PLAIN all requests goes to the saslauthd, without passing the extra information found in userPassword. Another issue is that the username sent to saslauthd is the username entered by the user, not the dn found when rewriting the username with authz-regexp. Is this by design or did I miss anything? Documentation states that pass-through should be working with SASL/PLAIN, but perhaps I misunderstood what it really meant? -- regards, Robin

3 2

Server is unwilling to perform
by anil beniwal 08 Mar '13

08 Mar '13

Hi We are getting "Server is unwilling to perform" error in our ldap log files. Can somebody guide me, why we are getting this. We are having everything running fine on all the ldap servers. We have enabled ssl/tls. And its working fine when we connect on port 636 from application. We are not using ssl/tls for replication. Mar 8 13:52:51 prodldap01 slapd[10659]: conn=160323 fd=13 ACCEPT from IP= 10.243.129.9:27525 (IP=0.0.0.0:636) Mar 8 13:52:51 prodldap01 slapd[10659]: conn=160323 fd=13 closed (TLS negotiation failure) Mar 8 13:52:56 prodldap01 slapd[10659]: conn=160324 fd=13 ACCEPT from IP= 10.243.129.9:44600 (IP=0.0.0.0:636) Mar 8 13:52:56 prodldap01 slapd[10659]: conn=160324 fd=13 closed (TLS negotiation failure) Mar 8 13:52:56 prodldap01 slapd[10659]: conn=160324 fd=13 closed (TLS negotiation failure) Mar 8 13:52:57 prodldap01 slapd[10659]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT Mar 8 13:52:57 prodldap01 slapd[10659]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Mar 8 13:52:57 prodldap01 slapd[10659]: do_syncrep2: rid=001 (53) Server is unwilling to perform Mar 8 13:52:57 prodldap01 slapd[10659]: do_syncrepl: rid=001 rc -2 retrying Please let me know , if more details are required. -- Thanks&Regards AB

1 0

why are ppolicy operational attributes not viewable by default?
by John Baker 08 Mar '13

08 Mar '13

We were testing out password policy and noticed that attributes like pwdFailureTime that are modified during operation are commented out in the schema so they can't be viewed by the admin. Does anybody know the reasoning for this? We are thinking that we will want to be able to see them for debugging problems when we implement a password policy. But I wondered if that can cause problems if we put them in the schema or if their are other ways to get to current values on accounts. -- John Baker Network Administrator Marlboro College Phone: 451-7551 Cell: 490-0066

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical