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

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.

Hello list,

Thanks for your help!

Op 07-12-15 om 11:28 schreef Terje Trane:

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.

I have created such an user account, and I see the user on the replicated server as "cn=samba,dc=domain,dc=nl" (so without ou=user like normal users).

Point is that it does not work for authentication Samba, the ACL's will be not good. I will have to study ACL's again to give it full read access.

With regards, Paul van der Vlis.

Op 07-12-15 om 09:50 schreef Dieter Klünter:

Am Sun, 6 Dec 2015 14:19:23 +0100 schrieb Paul van der Vlis paul@vandervlis.nl:

...

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 this a samba3 or a samba4 server?

Samba3.

This is what I use for authentitication in smb.conf: --- passdb backend = ldapsam:ldapi:/// ldap ssl = off ldap suffix = "dc=domain,dc=nl" ldap admin dn = "cn=admin,dc=domain,dc=nl" ldap machine suffix = ou=machines ldap user suffix = ou=users ldap group suffix = ou=groups ldap delete dn = no ---

So I use the user "cn=admin,dc=domain,dc=nl", and this user does not excist on the replicated LDAP when I check it with ldapsearch. So I can understand this does not work.

With regards, Paul van der Vlis.