openldap-technical

openldap-technical@openldap.org

9 participants
9866 discussions

RE: Client binding to a specific local address
by Quanah Gibson-Mount 11 May '17

11 May '17

--On Thursday, May 11, 2017 8:33 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > I'm working on an embedded LDAP application software that makes use of > the OpenLDAP client ldap and lber libraries, not the LDAP client > command-line utilities. For that reason, I didn't look into the client > utilities and narrowly thought of slapd -h (where -H option doesn't > exist). > > I see the client utilities ldapsearch, ldapadd, ldapmodify... have the > [-H ldapuri] option, but the library functions ldap_search, > ldap_search_ext, ldap_add, ldap_add_ext, ldap_modify, ldap_modify_ext, > etc. don't have an equivalent input argument. Is it correct that no > client library function supports specification of a local IP address? As I noted, the LDAP client tools all use the C API. Clearly you can pass in a URI when initializing the connection to create the filehandle that is later utilized by functions such as ldap_search, etc. I would strongly advise reading the ldap_open(3) man page, more specifically the ldap_initialize() function detailed there. I would also note that it is perfectly valid for "host" as described in the man page to be an IP address vs a literal hostname. My point in directing you to the clients is you can trivially see how they use the API to construct a connection, etc, using the LDAP C API. Hope that helps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Error adding schema: empty AttributeDescription
by Quanah Gibson-Mount 11 May '17

11 May '17

--On Thursday, May 11, 2017 12:15 PM +0100 Sami <s.aitalioulahcen(a)cnrst.ma> wrote: > Hello, > > The attribute type description, as per RFC2252, requires a space before > the closing parenthesis. It might be what's causing the error. I'd also note it's generally recommended to use slaptest (as documented) to convert existing schema files to LDIF format, to avoid errors such as this. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: Client binding to a specific local address
by Quanah Gibson-Mount 11 May '17

11 May '17

--On Wednesday, May 10, 2017 8:05 PM +0000 Daniel Le <daniel.le(a)exfo.com> wrote: > > > Hi, > > > > Is there an API to bind client to a local IP address? If not, how best to > directly handle a BER socket for such purpose? The reason is to direct > traffic to go through a specific interface of a host that has multiple > NICs. There is no option in ldap_set_option() for address binding. I > found the thread "listener question" from the OpenLDAP Technical > archives which asked a similar question, but not exactly the same. Use the IP address as the URI, like -H ldap://1.2.3.4:389 --quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Error adding schema: empty AttributeDescription
by Prentice Bisbal 11 May '17

11 May '17

Hello, I'm in the middle of upgrading our existing LDAP servers to new systems running OpenLDAP 2.4.40 on CentOS 6.9. I have over 10 years of experience managing LDAP directories in relatively simple environments, but this is my first time trying to use the dynamic runtime configuration engine. I'm trying to add all the schemas I need with slapadd before I add a dump of the directory from our old servers with slapadd. I need a kerberos schema, so I copied the kerberos schema from /usr/share/doc/krb5-server-ldap-1.10.3/kerberos.ldif, to /etc/openldap/schema and modified it so it could be added with slapadd rather than ldapmodify, like all the other files in that directory. Here's an example of the start of the file after making those changes: dn: cn=kerberos,cn=schema,cn=config objectClass: olcSchemaConfig cn: kerberos olcAttributeTypes: ( 2.16.840.1.113719.1.301.4.1.1 NAME 'krbPrincipalName' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) olcAttributeTypes: ( 1.2.840.113554.1.4.1.6.1 NAME 'krbCanonicalName' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE) olcAttributeTypes: ( 2.16.840.1.113719.1.301.4.3.1 NAME 'krbPrincipalType' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE) When I try to add that file with slapadd. I get this error: # slapadd -n0 -F /etc/openldap/slapd.d -l kerberos.ldif SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)): empty AttributeDescription slapadd: could not parse entry (line=1) _# 6.36% eta none elapsed none spd 18.6 M/s Closing DB... Running the same command debugging set to -1, I get the following: 59138493 => str2entry: "dn: cn=kerberos,cn=schema,cn=config objectClass: olcSchemaConfig cn: kerberos olcAttributeTypes: ( 2.16.840.1.113719.1.301.4.1.1 NAME 'krbPrincipalName' EQUALITY caseExactIA5Match SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26) " 59138493 >>> dnPrettyNormal: <cn=kerberos,cn=schema,cn=config> 59138493 <<< dnPrettyNormal: <cn=kerberos,cn=schema,cn=config>, <cn=kerberos,cn=schema,cn=config> 59138493 <= str2entry NULL (parse_line) SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)): empty AttributeDescription slapadd: could not parse entry (line=1) 59138493 slapadd shutdown: initiated 59138493 slapadd destroy: freeing system resources. Any ideas what I'm doing wrong? I made similar changes to an autofs schema file, and I was able to add that just fine. Do I need to number each olcAttributeType entry by putting a number in curly braces ({0}, {1,}, etc.) at the start of each olcAttributeTypes entry? -- Prentice

2 3

overlay ppolicy - atribute pwdhistory
by DÍEZ BARREIRO, ANA BELÉN 11 May '17

11 May '17

Hi, I am using ppolicy overlay and I don't want the user to change the password by setting the same value. If I put pwdinhistory = 1 then the new password can not be the same as the current one or the previous on (2 values). But with pwdinhistory = 0 you can put the same value. What would be the solution? Thanks!

2 2

Re: Antw: overlay ppolicy - atribute pwdhistory
by DÍEZ BARREIRO, ANA BELÉN 11 May '17

11 May '17

I know that, but I want to have it like this: that the same password can not be introduced. If I put pwdinhistory = 1 it also does not allow putting the previous one (not just the current one). And that should be possible. Regards, Ana. El 10/05/2017 a las 14:40, Ulrich Windl escribió: >>>> DÍEZ BARREIRO, ANA BELÉN <ana.diez(a)si.upct.es> schrieb am 09.05.2017 um > 14:40 > in Nachricht <85fdee58-2d7f-f443-4ff0-79a97c1058f3(a)si.upct.es>: >> Hi, >> >> I am using ppolicy overlay and I don't want the user to change the >> password by setting the same value. > Usually this is what users do to circumvent such a restriction: > 1) Change old pawword to new password > 2) Change new password to old password > > So a history of size 1 is rather useless, unless you place other restirctions > into effect. > Despite of that UNIX usually refuses a password that is not deifferent from > the current one... > > Regards, > Ulrich > >> If I put pwdinhistory = 1 then the new password can not be the same as >> the current one or the previous on (2 values). But with pwdinhistory = 0 >> you can put the same value. >> What would be the solution? >> >> Thanks! > > >

1 0

Client binding to a specific local address
by Daniel Le 10 May '17

10 May '17

Hi, Is there an API to bind client to a local IP address? If not, how best to directly handle a BER socket for such purpose? The reason is to direct traffic to go through a specific interface of a host that has multiple NICs. There is no option in ldap_set_option() for address binding. I found the thread "listener question" from the OpenLDAP Technical archives which asked a similar question, but not exactly the same. Thanks, Daniel

1 0

Re: ppolicy overlay - not seeming to function?
by Howard Chu 10 May '17

10 May '17

John Cooter wrote: > So, before I ask my question, here are my referenced objects, from a "slapcat -n 0": > dn: olcDatabase={2}hdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {2}hdb > olcDbDirectory: /var/lib/ldap > olcDbIndex: objectClass eq,pres > olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub > structuralObjectClass: olcHdbConfig > entryUUID: eb941fcc-bef3-1036-9d74-0d6e032eb747 > creatorsName: cn=config > createTimestamp: 20170426174545Z > olcAccess: {0}to dn.base="" by self write by dn="cn=ldapadmin,dc=XXXXXXX > ,dc=net" write by * read > olcAccess: {1}to * by self write by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" w > rite by * read > olcAccess: {2}to dn.subtree="ou=mail,ou=hosting,dc=XXXXXXX,dc=net" attrs= > userPassword,UseAppPassword,children,entry,objectClass,cn,sn,uid by self w > rite by dn="cn=ldapadmin,dc=XXXXXXX,dc=net" write by * auth by * read > olcSuffix: dc=XXXXXXXX,dc=net > olcRootDN: cn=ldapadmin,dc=XXXXXXX,dc=net > olcRootPW:: e1NTSEF9K2p6YnhXL0xQTDJKZFFIZitac3l6RzVXaEN3UEhQUkc= > entryCSN: 20170508155547.001404Z#000000#000#000000 > modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > modifyTimestamp: 20170508155547Z > > dn: olcOverlay={0}ppolicy,olcDatabase={2}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcPPolicyConfig > olcOverlay: {0}ppolicy > olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=XXXXXXX,dc=net > olcPPolicyHashCleartext: FALSE > olcPPolicyUseLockout: FALSE > olcPPolicyForwardUpdates: FALSE > structuralObjectClass: olcPPolicyConfig > > the passwordDefaul policy exists in the correct location, and appears to apply to all user objects BUT > > when I change a user object to a value that either violates the base policy (say, has only 4 characters instead of 5 or more), or would not conform to the check_password.so function, as established by various outside sources, it does not give me an error of any kind, and instead, writes the password to the DB and writes the following to the log: Reread the slapo-ppolicy(5) manpage. You're making modifications using the rootDN, which is documented to ignore any configured policies. > May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 STARTTLS > May 10 11:00:05 ldapv slapd[1984]: conn=1007 op=0 RESULT oid= err=0 text= > May 10 11:00:06 ldapv slapd[1984]: conn=1007 fd=11 TLS established tls_ssf=256 ssf=256 > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" method=128 > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 BIND dn="cn=ldapadmin,dc=XXXXXXX,dc=net" mech=SIMPLE ssf=0 > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=1 RESULT tag=97 err=0 text= > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD dn="uid=USER,cn=TESTDOMAIN.com,ou=domain,ou=mail,ou=hosting,dc=XXXXXXX,dc=net" > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 MOD attr=userPassword > May 10 11:00:06 ldapv slapd[1984]: conn=1007 op=2 RESULT tag=103 err=0 text= > > And the entry, as referenced by phpLDAPadmin, appears to correspond to the "bad" password. How can I go about confirming that the password policy is being enforced? Bind as a regular user identity instead of the rootDN when making a change. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Multimaster Replication
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Monday, May 08, 2017 4:51 PM +0000 "Weiner, Michael" <weinerm(a)ccf.org> wrote: > Searching through the archives, helpful information, but I wasn't able to > find anything that quite matched my issue. Some background, I am running > CentOS 7 with OpenLDAP version 2.4.40 and I have been following along a > tutorial I found here: OpenLDAP 2.4.40 contained a number of serious bugs. I strongly advise against using it, particularly with MMR. As for your ldapadd, did you hit control-D when done, so it would exit? Otherwise, it's waiting on continued input from you. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: ppolicy overlay - not seeming to function?
by Quanah Gibson-Mount 10 May '17

10 May '17

--On Wednesday, May 10, 2017 12:20 PM -0400 John Cooter <jcooter(a)atlantech.net> wrote: > And the entry, as referenced by phpLDAPadmin, appears to correspond to > the "bad" password. How can I go about confirming that the password > policy is being enforced? Your log shows that the LDAPv3 extended password operation was not used. The bug is in your client code. Hope that helps! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical