Op 06-12-15 om 18:45 schreef Quanah Gibson-Mount:

--On Sunday, December 06, 2015 2:19 PM +0100 Paul van der Vlis paul@vandervlis.nl wrote:

...

Hello,

I have a replicated LDAP and a few Windows PC's what want to authenticate using Samba. Normally I use "smbpasswd -w" to give the ldap admin dn, but because it's replicated there is no ldap admin!

Is there a way to authenticate using a replicated LDAP?

I've no clue what you mean here. If the data is replicated, then the same data that is on the master is on the replica, and one can authenticate to the replica just like they would to the master.

You would say, but that's not the case. On the replica I don't have an "admin" user. When I do:

ldapsearch -x -b "cn=admin,dc=domain,dc=nl" -H ldapi:///

On the replica I get: "no such object". On the master I get: "0 Success".

The replicated LDAP works fine with Linux.

I don't care the LDAP admin user is replicated or the replicated server has it's own admin user. But I need an admin user with a password.

This are the settings on the replica: provider=ldaps://ldap.domain.nl searchbase=dc=domain,dc=nl type=refreshAndPersist schemachecking=on interval=00:01:00:00 bindmethod=simple tls_reqcert=never tls_cacert=/etc/ssl/certs/CAself-cert.pem retry="60 +" binddn="dc=domain,dc=nl" credentials=xxxxx

I'm guessing what you mean is that portions of Samba unique to samba that have nothing to do with LDAP are not present, and thus samba related tools don't work. I'd suggest discussing with the Samba folks on how to properly replicate Samba environments.

Samba is using the LDAP admin user. This user does not work on the replica. So first I want to have that correct and I expect it will work then.

With regards, Paul van der Vlis.

--On Sunday, December 06, 2015 1:27 PM -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:

The above is an anonymous search. Do your acls actually allow results to be returned with anonymous searches?

You may also want to slapcat the DB of both servers and compare. In addition, if the "admin" user is actually only defined in the config database as the rootdn, there's no requirement it exist in the datadb. Since we have no clue what your setup is, we can only shoot in the dark and make random guesses.

--Quanah

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

--On Sunday, December 06, 2015 10:43 PM +0100 Paul van der Vlis paul@vandervlis.nl wrote:

Op 06-12-15 om 22:27 schreef Quanah Gibson-Mount:

...

--On Sunday, December 06, 2015 10:13 PM +0100 Paul van der Vlis paul@vandervlis.nl wrote:

...

ldapsearch -x -b "cn=admin,dc=domain,dc=nl" -H ldapi:///

The above is an anonymous search. Do your acls actually allow results to be returned with anonymous searches?

Yes. Something like this gives "0 Success" on the replicated server: ldapsearch -x -b "cn=paul,ou=users,dc=domain,dc=nl" -H ldapi:///

Not sure what your point is. Do you mean it actually returns that user entry *as well* as returning success? There are very few instances where it will /not/ return success. Do not confuse a success result with meaning that your ACLs are correct.

And the ldapsearch with cn=admin works fine on the master.

Again, as I noted before, this could be a rootdn that doesn't actually exist in the data backed database.

Again, you should slapcat both the master and replica and confirm their contents match.

You may also which to see if your admin user actually exists in the data db on the master, or if it is a rootdn that only exists in the configuration.

--Quanah

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

Op 07-12-15 om 01:09 schreef Quanah Gibson-Mount:

--On Sunday, December 06, 2015 10:43 PM +0100 Paul van der Vlis paul@vandervlis.nl wrote:

...

Op 06-12-15 om 22:27 schreef Quanah Gibson-Mount:

...

--On Sunday, December 06, 2015 10:13 PM +0100 Paul van der Vlis paul@vandervlis.nl wrote:

...

ldapsearch -x -b "cn=admin,dc=domain,dc=nl" -H ldapi:///

The above is an anonymous search. Do your acls actually allow results to be returned with anonymous searches?

Yes. Something like this gives "0 Success" on the replicated server: ldapsearch -x -b "cn=paul,ou=users,dc=domain,dc=nl" -H ldapi:///

Not sure what your point is. Do you mean it actually returns that user entry *as well* as returning success?

Correct.

There are very few instances where it will /not/ return success.

On the replication it says: "no such object". And that's the problem I want to fix.

Do not confuse a success result with meaning that your ACLs are correct.

So far I know the ACL's are correct. This system works many years with many Linux clients, now they also want Windows. On the location of the master, they allready have a few Windows PC's for some years, and the authentication works fine.

...

And the ldapsearch with cn=admin works fine on the master.

Again, as I noted before, this could be a rootdn that doesn't actually exist in the data backed database.

Again, you should slapcat both the master and replica and confirm their contents match.

I expect they don't match ;-)

You may also which to see if your admin user actually exists in the data db on the master, or if it is a rootdn that only exists in the configuration.

It will be a only in cn=config.

This is the way I create a LDAP admin: ----- cat <<EOF >slapd-database.ldif dn: olcDatabase={1}hdb,cn=config changeType: modify replace: olcDbConfig olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE - replace: olcRootPW olcRootPW: ${LDAP_ADMIN_HASH} EOF ldapmodify -v -Y EXTERNAL -H ldapi:/// -f slapd-database.ldif -----

See more here: https://wiki.debian.org/nfs4-kerberos-ldap I am the author of the article.

With regards, Paul van der Vlis.

--Quanah

--

Quanah Gibson-Mount Platform Architect Zimbra, Inc.

---

Zimbra :: the leader in open source messaging and collaboration

On 07.12.2015 10:22, Paul van der Vlis wrote:

It will be a only in cn=config.

This is the way I create a LDAP admin:

cat <<EOF >slapd-database.ldif dn: olcDatabase={1}hdb,cn=config changeType: modify replace: olcDbConfig olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE

replace: olcRootPW olcRootPW: ${LDAP_ADMIN_HASH} EOF ldapmodify -v -Y EXTERNAL -H ldapi:/// -f slapd-database.ldif

---

The rootdn (with accompanying password) is, at least the way I think it is meant, a full-access-to-everything root account for use when setting up the directory. Only.

Then, good practice is to make the account(s) you need to administer and run the system in the LDAP tree, with appropriate ACLs, and disable the rootdn. (In slapd.conf it can be done by just commenting out the rootdn/rootpw lines).

So, for your samba servers you should make an account, e.g. cn=sambaserver, that is only for that use (and is replicated), and with rights only to what it really needs and not to the whole LDAP tree.

Terje Trane wrote:

On 07.12.2015 10:22, Paul van der Vlis wrote:

...

It will be a only in cn=config.

This is the way I create a LDAP admin:

cat <<EOF >slapd-database.ldif dn: olcDatabase={1}hdb,cn=config changeType: modify replace: olcDbConfig olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE

replace: olcRootPW olcRootPW: ${LDAP_ADMIN_HASH} EOF ldapmodify -v -Y EXTERNAL -H ldapi:/// -f slapd-database.ldif

---

The rootdn (with accompanying password) is, at least the way I think it is meant, a full-access-to-everything root account for use when setting up the directory. Only.

No, the rootdn is also used by various internal administrative functions. It is used continuously, not just for setup.

Then, good practice is to make the account(s) you need to administer and run the system in the LDAP tree, with appropriate ACLs, and disable the rootdn. (In slapd.conf it can be done by just commenting out the rootdn/rootpw lines).

Comment out the rootpw, sure. That prevents external clients from using it. But always leave some rootdn defined.

So, for your samba servers you should make an account, e.g. cn=sambaserver, that is only for that use (and is replicated), and with rights only to what it really needs and not to the whole LDAP tree.