May 2017 - openldap-technical

Re: Antw: overlay ppolicy - atribute pwdhistory

by DÍEZ BARREIRO, ANA BELÉN

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! > > >

6 years

1
0
0 / 0

Client binding to a specific local address

by Daniel Le

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

6 years

1
0
0 / 0

Re: ppolicy overlay - not seeming to function?

by Howard Chu

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/

6 years

1
0
0 / 0

Re: Multimaster Replication

by Quanah Gibson-Mount

--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>

6 years

2
1
0 / 0

Re: ppolicy overlay - not seeming to function?

by Quanah Gibson-Mount

--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>

6 years

1
0
0 / 0

Multimaster Replication

by Weiner, Michael

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: http://linoxide.com/linux-how-to/setup-openldap-multi-master-replication-... everything goes well, of course,until the very last step where I have to add the replication information, I recreated this ldif: dn: cn=config changetype: modify replace: olcServerID olcServerID: 101 ldap://lri-ldap1 olcServerID: 201 ldap://lri-ldap2 olcServerID: 301 ldap://lri-ldap3 olcServerID: 401 ldap://lri-ldap4 dn: olcDatabase={2}hdb,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=ldap://lri-ldap1:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 olcSyncRepl: rid=002 provider=ldap://lri-ldap2:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 olcSyncRepl: rid=003 provider=ldap://lri-ldap3:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 olcSyncRepl: rid=004 provider=ldap://lri-ldap4:389/ bindmethod=simple binddn="cn=admin,dc=lerner,dc=ccf,dc=org" credentials=password12 searchbase="dc=lerner,dc=ccf,dc=org" scope=sub schemachecking=on type=refreshAndPersist retry="30 5 300 3" interval=00:00:05:00 - add: olcMirrorMode olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov and then ldapmodify -Y EXTERNAL -H ldapi:/// -f rp.ldif on all 4 masters, and what I get is, they are all just sitting there not providing me with a prompt: [root@lri-ldap4 openldap]# ldapadd -Y EXTERNAL -H ldapi:/// -f rp.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn=config" modifying entry "olcDatabase={2}hdb,cn=config" adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" and I cannot tell what it is actually doing at this stage. I check systemctl status spald: May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=0 RESULT tag=97 err=0 text= May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=1 MOD dn="cn=config" May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=1 MOD attr=olcServerID May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=1 RESULT tag=103 err=0 text= May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=2 MOD dn="olcDatabase={2}hdb,cn=config" May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=2 MOD attr=olcSyncRepl olcMirrorMode May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=2 RESULT tag=103 err=0 text= May 08 11:17:15 lri-ldap1 slapd[3856]: conn=1000 op=3 ADD dn="olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" And that's where it stops, but I never get a prompt on any of the masters. Has anyone else seen this? Where did I go wrong? And how can I move forward? Thanks in advance Michael =================================== Please consider the environment before printing this e-mail Cleveland Clinic is ranked as one of the top hospitals in America by U.S.News & World Report (2015). Visit us online at http://www.clevelandclinic.org for a complete listing of our services, staff and locations. Confidentiality Note: This message is intended for use only by the individual or entity to which it is addressed and may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. Thank you.

6 years

2
1
0 / 0

ppolicy overlay - not seeming to function?

by John Cooter

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: 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?

6 years

1
0
0 / 0

Re: [SOLVED] Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)

by Quanah Gibson-Mount

--On Monday, May 08, 2017 12:16 PM +0000 mailing lists <listas.correo(a)yahoo.es> wrote: > if I add the port to the updateref directive I can reproduce the > behaviour (anonymous bind vs bind with the identity configurated in the > chain overlay) only by switching the updateref beetwen the url with port > and without it. Please see <http://www.openldap.org/its/index.cgi/?findid=7768>, it looks like you would need to set a corresponding olcDbUri attribute to match your updateref value Can you let me know if this resolves the issue? If so, I can update the documentation accordingly. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years

2
1
0 / 0

Re: Secure replication

by Quanah Gibson-Mount

--On Tuesday, May 09, 2017 2:11 AM +0000 "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov> wrote: Hi Elizabeth, > If "ldap://" is secure already then I do not need to proceed further. That says nothing about whether or not your configuration is secure. Again, if it is "ldap://" with the startTLS LDAPv3 extension, and you've configured it be required that it succeed, then it is secure. You've not provided the information that would be necessary to make such a determination. I would again advise reading the slapd-config(5) man page for the olcSyncRepl attribute, specifically the bits on the starttls, tls_cacert/tls_cacertdir, tls_cipher_suite, and tls_protocol_min configuration parameters. You may also want to set olcSecurity (A value of "ssf=1" requires any and all connections to the server be encrypted). Changing this value from the default requires a server restart for it to go into effect. > SSLv3 > TLSv1.2 Those look like protocol versions, not cipher suites. ;) > Why is version 2.4.40 unsafe for multi-master replication? I can upgrade > at a later time I just wanted to find out how to enable ldaps between the > two servers. You can read through the OpenLDAP Release notes here: <http://www.openldap.org/software/release/changes.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

6 years

1
0
0 / 0

Re: Secure replication

by Michael Ströder

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 08.05.2017 um 23:39 in >> When running different replicas which terminate TLS themselves you can issue a >> different server cert with distinct subject-DN for each of them and put FQDN(s) of >> the same HA address(es) (e.g. of your load-balancer(s)) into subjectAltName >> extension in all these different server certs. > > So you have one certificate for all servers, and the answer is that you cannot > have different certificates? If so, we had discussed that before. I thought you > were advising otherwise now, and I was surprised how that would work. Did you deliberately misread my answer? I cannot imagine how I can make more clear that I have different certs on all replicas. And probably you also misread my former postings about that topic. Ciao, Michael.

6 years

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2017