RE: structural objectclass checking

[Vandenburgh, Steve Y]

Markus,

You might review the objectclass definitions for your data.  There is no issue 
with multiple STRUCTURAL objectclasses on the same object as long as they are 
part of the same hierarchy e.g.

dn: uid=user,ou=people,dc=example,dc=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: customizedObjectClassBasedOnInetOrgPerson
.
.
.

There might also be the opportunity to convert some structural classes to 
auxiliary.


From: openldap-technical  On Behalf Of 
markus.st...@t-systems.com
Sent: Wednesday, January 8, 2020 8:25 AM
To: openldap-technical@openldap.org
Subject: structural objectclass checking

Hi,

is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL 
objectclasses?

I know it's illegal per standard to have either no or multiple objectclasses of 
STRUCTURAL type on an entry.
Unfortunately in the enterprise world it is very common that you have to deal 
with existing data which is even beyond your control. Our LDAP is full of such 
'bad' records, making imports into OpenLDAP fail for 50% of our entries.
I'm trying to present OpenLDAP as an alternative to the commercial LDAP 
software my company is currently running but I need to come up with a solution 
to this in order to convince our managers and engineering.
Competition such as Oracle Unified Dir have an option to selectively disable 
this type of checking.
Is there a way to do it in OpenLDAP via config? If no, would it be rather easy 
or hard to add that to the code myself ? I once made a similar patch but it had 
to be applied in a single location within the source only.

Thanks
Best regards
Markus

This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.

Re: Replication account problem

[Quanah Gibson-Mount]

--On Wednesday, January 8, 2020 4:16 PM +0100 Vincent Ducot 
 wrote:




Hi all,
 I'm testing multi-master replication between (at least 2) openldap nodes
(2.4.45, on Ubuntu 18.04) and facing a problem with replication account.




Any idea of what could cause this problem ?



# {1}mdb, config
 dn: olcDatabase={1}mdb,cn=config
 objectClass: olcDatabaseConfig
 objectClass: olcMdbConfig
 olcDatabase: {1}mdb
 olcDbDirectory: /var/lib/ldap
 olcSuffix: dc=nodomain
 olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
none
 olcAccess: {1}to attrs=shadowLastChange by self write by * read
 olcAccess: {2}to * by * read



# {2}mdb, config
 dn: olcDatabase={2}mdb,cn=config
 objectClass: olcDatabaseConfig
 objectClass: olcMdbConfig
 olcDatabase: {2}mdb
 olcDbDirectory: /var/lab/ldap
 olcSuffix: dc=foo,dc=bar
 olcAccess: {0}to attrs=userPassword by self =xw by anonymous auth by *
none
 olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
user
  s read by * none
 olcAccess: {2}to * by dn="uid=rpuser,dc=foo,dc=bar" read
 olcAccess: {3}to * by dn="uid=rpuser,dc=foo,dc=bar" write



I see multiple problems with your configuration.

a) You have two different databases storing their DBs in the same location 
(/var/lib/ldap).  I can't even imagine the havoc and destruction that would 
cause.


b) Your ACLs are broken.  The "rpuser" account has no ability to replicate 
userPassword, since it can't read it.  Also, ACLs #2 and #3 here will never 
be evaluated, since it's already covered in ACL#1 (by users read).  Since 
it can't replicate userPassword, that value is getting lost from server#2, 
explaining why you can't bind to it after replication starts.


Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: structural objectclass checking

[Quanah Gibson-Mount]

--On Wednesday, January 8, 2020 3:25 PM + markus.st...@t-systems.com 
wrote:



is there a way to disable OpenLDAP checking entries for existence of
STRUCTURAL objectclasses?


No.  This is a hard requirement.  The best option would be to fix the bad 
data in your upstream system.


Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: ldapsearch utility

[Quanah Gibson-Mount]

--On Tuesday, January 7, 2020 4:48 PM -0500 Peter Sui  
wrote:






Hi Quanah,
       Thanks for your response, another question about the SASL. I
know for the ldap server, some settings must be done, what about for the
client side? If I only installed the open ldap library and client tools,
and if I want to use SASL GSSAPI, will this be enough ? do I need to
install other modules like Kerberos V?


Hi Peter,

The majority of SASL mechanism are handled by cyrus-sasl, so the related 
cyrus-sasl modules must be installed for a given mechanism.  Additionally, 
any system that wants to use SASL/GSSAPI must be able to obtain a kerberos 
ticket for the related user prior to the use of the ldap* tools.


Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: Openldap support SHA-256 or SHA-3.

[Geert Hendrickx]

On Tue, Jan 07, 2020 at 12:22:05 -0800, Quanah Gibson-Mount wrote:
> After deploying the sha2 module, all users must change their password so
> the hash gets updated.  There is no way to magically convert existing
> hashes from SSHA1 to another scheme.


A controversial solution, but slapd could re-hash the password after a
succesful authentication.


Geert


-- 
geert.hendrickx.be :: ge...@hendrickx.be :: PGP: 0xC4BB9E9F
This e-mail was composed using 100% recycled spam messages!

Re: Replication account problem

[A. Schulze]

Am 08.01.20 um 16:16 schrieb Vincent Ducot:
> Hi all,
> I'm testing multi-master replication between (at least 2) openldap nodes 
> (2.4.45, on Ubuntu 18.04) and facing a problem with replication account.

At some point in time I decided to create a separate database as 
replication-account

slapd.conf:
database ldif
directory /empty
suffix "dc=syncrepl"
access to dn.base="dc=syncrepl" by * auth
rootdn "dc=syncrepl"
rootpw "{PLAIN}secret"

This account exist per configuration even on an "empty" syncrepl consumer and 
is allowed to read/write the database to be replicated.
It will not be replicated itself an avoid the issue you describe. N-way 
replication can start from zero.

If this should be insecure, I hope, somebody will correct me (and the archive), 
please.

Andreas

Re: Openldap support SHA-256 or SHA-3.

[Quanah Gibson-Mount]

--On Wednesday, January 8, 2020 10:27 AM +0100 Simone Piccardi 
 wrote:



Il 08/01/20 03:05, Quanah Gibson-Mount ha scritto:


In any case, I've been advocating for several years now to get rid of
SSHA as the default hashing mechanism and replace it with something that
may actually have some security value.


But in the current version it better to use the contrib module, or
delegate the hashing to the C library? I'm currently using on new install:

password-hash {CRYPT}
password-crypt-salt-format "$6$%.16s"

but I'm using only Linux, I don't know if this is applicable on other OS.


The use of CRYPT may be non-portable.  In addition to the SSHA2 password 
module, there's a module on github that allows the use of bcrypt:




--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

structural objectclass checking

[Markus.Storm]

Hi,

is there a way to disable OpenLDAP checking entries for existence of STRUCTURAL 
objectclasses?

I know it's illegal per standard to have either no or multiple objectclasses of 
STRUCTURAL type on an entry.
Unfortunately in the enterprise world it is very common that you have to deal 
with existing data which is even beyond your control. Our LDAP is full of such 
'bad' records, making imports into OpenLDAP fail for 50% of our entries.
I'm trying to present OpenLDAP as an alternative to the commercial LDAP 
software my company is currently running but I need to come up with a solution 
to this in order to convince our managers and engineering.
Competition such as Oracle Unified Dir have an option to selectively disable 
this type of checking.
Is there a way to do it in OpenLDAP via config? If no, would it be rather easy 
or hard to add that to the code myself ? I once made a similar patch but it had 
to be applied in a single location within the source only.

Thanks
Best regards
Markus

Replication account problem

[Vincent Ducot]

Hi all,
I'm testing multi-master replication between (at least 2) openldap nodes
(2.4.45, on Ubuntu 18.04) and facing a problem with replication account.

I set up configuration for node1 and node2 (see configuration below),
and rpuser account for replication (with same hashed password on both
nodes).
I can connect to node1 and node2 with rpuser account : ldapsearch -H
ldap://node1-vpn -W -D "uid=rpuser,dc=foo,dc=bar" -b "dc=foo,dc=bar"
Then I add a group or a user to a node to test replication with
ldapadd -H ldap://node1-vpn -W -D "cn=admin,dc=foo,dc=bar" -f
/tmp/openldap/rep_test_groupadd.ldif

and rep_test_groupadd.ldif:

dn: cn=testgroup,dc=foo,dc=bar
objectClass: top
objectClass: posixGroup
gidNumber: 456

The new group or user is replicated on the other node, but then the
rpuser's password doesn't work anymore on the other node.
I can't connect anymore with ldapsearch -H ldap://node2-vpn -W -D
"uid=rpuser,dc=foo,dc=bar" -b "dc=foo,dc=bar"
and I got errors messages for replication in /var/log/syslog
slap_client_connect: URI=ldap://node2-vpn DN="uid=rpuser,dc=foo,dc=bar"
ldap_sasl_bind_s failed (49)

rpuser's password is still valid on node1

Any idea of what could cause this problem ?
Thanks

Vincent



# config
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcDisallows: bind_anon
olcLogLevel: any
olcPidFile: /var/run/slapd/slapd.pid
olcRequires: authc
olcToolThreads: 1
olcServerID: 0 ldap:///
olcServerID: 1 ldap://node1-vpn
olcServerID: 2 ldap://node2-vpn

# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb

# module{1}, config
dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModuleLoad: {0}syncprov.la

# {0}mdb, config
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb

# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read
olcSizeLimit: 500

# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break

# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=nodomain
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by *
none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read
olcLastMod: TRUE
olcRequires: authc
olcRootDN: cn=admin,dc=nodomain
olcRootPW: {SSHA}HdZbPd66TxCjeYEIAASbAQTnvFh3GOTw
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824

# {2}mdb, config
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lab/ldap
olcSuffix: dc=foo,dc=bar
olcAccess: {0}to attrs=userPassword by self =xw by anonymous auth by * none
olcAccess: {1}to * by dn="cn=admin,dc=foo,dc=bar" write by self write by
user
 s read by * none
olcAccess: {2}to * by dn="uid=rpuser,dc=foo,dc=bar" read
olcAccess: {3}to * by dn="uid=rpuser,dc=foo,dc=bar" write
olcLastMod: TRUE
olcLimits: {0}dn.exact="uid=rpuser,dc=foo,dc=bar" time.soft=unlimited 
time.h
 ard=unlimited size.soft=unlimited size.hard=unlimited
olcRequires: authc
olcRootDN: cn=admin,dc=foo,dc=bar
olcRootPW: {SSHA}zL8CSrnkBacsebLUsJ+dzva6eQ7xcyZJ
olcSyncrepl: {0}rid=101 provider=ldap://node1-vpn binddn="uid=rpuser,dc=foo,
 dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar"
type=r
 efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcSyncrepl: {1}rid=102 provider=ldap://node2-vpn binddn="uid=rpuser,dc=foo,
 dc=bar" bindmethod=simple credentials=rppwd searchbase="dc=foo,dc=bar"
type=r
 efreshOnly interval=00:00:00:20 retry="5 10 20 10" timeout=1
olcMirrorMode: TRUE
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: entryUUID  eq
olcDbIndex: entryCSN  eq
olcDbMaxSize: 1073741824

# {0}syncprov, {2}mdb, config
dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov

Re: Openldap support SHA-256 or SHA-3.

[Ondřej Kuzník]

On Wed, Jan 08, 2020 at 01:52:11PM +0100, "POISSON Frédéric" wrote:
> Hello,
> 
> Does this project 
> https://github.com/sonOfRa/openldap/tree/argon2/contrib/slapd-modules/passwd/argon2
>  could respond or it is off topic ?

This is being tracked in ITS#8575 and should be part of 2.5 release.

-- 
Ondřej Kuzník
Senior Software Engineer
Symas Corporation   http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP

Re : Re: Openldap support SHA-256 or SHA-3.

[POISSON Frédéric]

Hello,

Does this project 
https://github.com/sonOfRa/openldap/tree/argon2/contrib/slapd-modules/passwd/argon2
 could respond or it is off topic ?


Regards,

Le 08/01/20 00:47, Howard Chu   a écrit : 
> 
> Quanah Gibson-Mount wrote:
> > 
> > 
> > --On Tuesday, January 7, 2020 10:44 AM -0800 rammohan ganapavarapu 
> >  wrote:
> > 
> >>
> >> Does openldap support SHA-256 or SHA-3 schemes? to address the below
> >> issues?
> > 
> > There is a module in contrib that is included with most vendor builds that 
> > allows up to SSHA512. I've long suggested using it. The default of SSHA1 is
> > mandated by RFC (which IMHO needs updating at this point).
> 
> Just to note, both SHA2 and SHA3 are designed to be cheap to compute and easy 
> to implement
> in hardware. Neither of these are desirable properties for a password hash. 
> At this point
> we should only be talking about Argon2, which won the password hashing 
> competition.
> 
> https://github.com/P-H-C/phc-winner-argon2
> 
> As always - patches welcome.
> 
> -- 
>  -- Howard Chu
>  CTO, Symas Corp. http://www.symas.com
>  Director, Highland Sun http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP http://www.openldap.org/project/
> 
> 
-- 

Frederic Poisson

 
 

Re: Openldap support SHA-256 or SHA-3.

[Simone Piccardi]

Il 08/01/20 03:05, Quanah Gibson-Mount ha scritto:
> 
> In any case, I've been advocating for several years now to get rid of
> SSHA as the default hashing mechanism and replace it with something that
> may actually have some security value.

But in the current version it better to use the contrib module, or
delegate the hashing to the C library? I'm currently using on new install:

password-hash {CRYPT}
password-crypt-salt-format "$6$%.16s"

but I'm using only Linux, I don't know if this is applicable on other OS.

Simone