samba4 alpha5 with openldap

[Oliver Liebel-2]

hi andrew,

i had just setup samba4 alpha5 with openldap 2.4.10, using the following
configuration:

backend-provision:
setup/provision-backend --realm=ldap.local.site --domain=LDAP
--ldap-manager-pass=linux --ldap-backend-type=openldap
--server-role='domain controller'

then started slapd using another port, not ldapi:
/usr/lib/openldap/slapd -f /usr/local/samba/private/ldap/slapd.conf -h
"ldap://192.168.198.11:9000/" -d 1

the final provision runs ok, using these settings:
setup/provision --realm=ldap.local.site --domain=LDAP  
--server-role='domain controller'
--ldap-backend="ldap://192.168.198.11:9000/"
--simple-bind-dn="CN=Manager,dc=ldap,dc=local,dc=site" --password=linux
--adminpass=linux --ldap-backend-type=openldap

when i start smbd (smbd -i -d 4) i got the following errors:
- from smbd:
-------------------------------------
Starting GENSEC mechanism sasl-DIGEST-MD5
added interface ip=192.168.198.11 nmask=255.255.255.0
gensec_sasl: DIGEST-MD5 client step 2
ldb: Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS -  
<SASL(-13): user not found: no secret in database> <>
ldb: Failed to connect to 'ldap://192.168.198.11:9000/'

(after that, all other actions are failing due to the failed bind)
-------------------------------------

-from slapd :
------------------------------------
SASL [conn=8] Debug: DIGEST-MD5 server step 2
slap_sasl_getdn: u:id converted to
uid=LDAPMASTER$,cn=ldap.local.site,cn=DIGEST-MD5,cn=auth
 >>> dnNormalize: <uid=LDAPMASTER$,cn=ldap.local.site,cn=DIGEST-MD5,cn=auth>
<<< dnNormalize: <uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth>
==>slap_sasl2dn: converting SASL name
uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth to a DN
==> rewrite_context_apply [depth=1]
string='uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth'
==> rewrite_rule_apply
rule='uid=([^,]*),cn=ldap.local.site,cn=digest-md5,cn=auth'
string='uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth' [1
pass(es)]
==> rewrite_context_apply [depth=1]
res={0,'ldap:///DC=ldap,DC=local,DC=site??sub?(samAccountName=ldapmaster$)'}
slap_parseURI: parsing
ldap:///DC=ldap,DC=local,DC=site??sub?(samAccountName=ldapmaster$)
ldap_url_parse_ext(ldap:///DC=ldap,DC=local,DC=site??sub?(samAccountName=ldapmaster$))
put_filter: "(samAccountName=ldapmaster$)"
put_filter: simple
put_simple_filter: "samAccountName=ldapmaster$"
ber_scanf fmt ({mm}) ber:
 >>> dnNormalize: <DC=ldap,DC=local,DC=site>
<<< dnNormalize: <dc=ldap,dc=local,dc=site>
slap_sasl2dn: performing internal search (base=dc=ldap,dc=local,dc=site,
scope=2)
=> hdb_search
bdb_dn2entry("dc=ldap,dc=local,dc=site")
search_candidates: base="dc=ldap,dc=local,dc=site" (0x00000001) scope=2
=> hdb_dn2idl("dc=ldap,dc=local,dc=site")
=> bdb_equality_candidates (objectClass)
=> key_read
<= bdb_index_read: failed (-30989)
<= bdb_equality_candidates: id=0, first=0, last=0
=> bdb_equality_candidates (sAMAccountName)
=> key_read
<= bdb_index_read 1 candidates
<= bdb_equality_candidates: id=1, first=44, last=44
bdb_search_candidates: id=1 first=44 last=44
send_ldap_result: conn=8 op=2 p=3
<==slap_sasl2dn: Converted SASL name to cn=ldapmaster,ou=domain
controllers,dc=ldap,dc=local,dc=site
slap_sasl_getdn: dn:id converted to cn=ldapmaster,ou=domain
controllers,dc=ldap,dc=local,dc=site
=> hdb_search
bdb_dn2entry("cn=ldapmaster,ou=domain controllers,dc=ldap,dc=local,dc=site")
slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined
send_ldap_result: conn=8 op=2 p=3
SASL [conn=8] Failure: no secret in database
---------------------------------

the sasl2dn conversion looks allright for me;
maybe this is the most intersting part:
--->  bdb_dn2entry("cn=ldapmaster,ou=domain
controllers,dc=ldap,dc=local,dc=site") <---
---> slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type
undefined  <----

any ideas?

greetings,
oliver






____________
Virus checked by G DATA AntiVirusKit
Version: AVK 18.4606 from 23.07.2008
Virus news: www.antiviruslab.com

[Oliver Liebel]

in addition to my last mail, using the latest samba4 from git
(4.0.0alpha6-GIT-a7bfa1f) together with ol 2.4.11
the problem mentioned below disappear.

greetings,
oliver

Oliver Liebel schrieb:

> hi andrew,
>
> i had just setup samba4 alpha5 with openldap 2.4.10, using the
> following configuration:
>
> backend-provision:
> setup/provision-backend --realm=ldap.local.site --domain=LDAP
> --ldap-manager-pass=linux --ldap-backend-type=openldap
> --server-role='domain controller'
>
> then started slapd using another port, not ldapi:
> /usr/lib/openldap/slapd -f /usr/local/samba/private/ldap/slapd.conf -h
> "ldap://192.168.198.11:9000/" -d 1
>
> the final provision runs ok, using these settings:
> setup/provision --realm=ldap.local.site --domain=LDAP  
> --server-role='domain controller'
> --ldap-backend="ldap://192.168.198.11:9000/"
> --simple-bind-dn="CN=Manager,dc=ldap,dc=local,dc=site"
> --password=linux --adminpass=linux --ldap-backend-type=openldap
>
> when i start smbd (smbd -i -d 4) i got the following errors:
> - from smbd:
> -------------------------------------
> Starting GENSEC mechanism sasl-DIGEST-MD5
> added interface ip=192.168.198.11 nmask=255.255.255.0
> gensec_sasl: DIGEST-MD5 client step 2
> ldb: Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS -  
> <SASL(-13): user not found: no secret in database> <>
> ldb: Failed to connect to 'ldap://192.168.198.11:9000/'
>
> (after that, all other actions are failing due to the failed bind)
> -------------------------------------
>
> -from slapd :
> ------------------------------------
> SASL [conn=8] Debug: DIGEST-MD5 server step 2
> slap_sasl_getdn: u:id converted to
> uid=LDAPMASTER$,cn=ldap.local.site,cn=DIGEST-MD5,cn=auth
> >>> dnNormalize:
> <uid=LDAPMASTER$,cn=ldap.local.site,cn=DIGEST-MD5,cn=auth>
> <<< dnNormalize:
> <uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth>
> ==>slap_sasl2dn: converting SASL name
> uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth to a DN
> ==> rewrite_context_apply [depth=1]
> string='uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth'
> ==> rewrite_rule_apply
> rule='uid=([^,]*),cn=ldap.local.site,cn=digest-md5,cn=auth'
> string='uid=ldapmaster$,cn=ldap.local.site,cn=digest-md5,cn=auth' [1
> pass(es)]
> ==> rewrite_context_apply [depth=1]
> res={0,'ldap:///DC=ldap,DC=local,DC=site??sub?(samAccountName=ldapmaster$)'}
>
> slap_parseURI: parsing
> ldap:///DC=ldap,DC=local,DC=site??sub?(samAccountName=ldapmaster$)
> ldap_url_parse_ext(ldap:///DC=ldap,DC=local,DC=site??sub?(samAccountName=ldapmaster$))
>
> put_filter: "(samAccountName=ldapmaster$)"
> put_filter: simple
> put_simple_filter: "samAccountName=ldapmaster$"
> ber_scanf fmt ({mm}) ber:
> >>> dnNormalize: <DC=ldap,DC=local,DC=site>
> <<< dnNormalize: <dc=ldap,dc=local,dc=site>
> slap_sasl2dn: performing internal search
> (base=dc=ldap,dc=local,dc=site, scope=2)
> => hdb_search
> bdb_dn2entry("dc=ldap,dc=local,dc=site")
> search_candidates: base="dc=ldap,dc=local,dc=site" (0x00000001) scope=2
> => hdb_dn2idl("dc=ldap,dc=local,dc=site")
> => bdb_equality_candidates (objectClass)
> => key_read
> <= bdb_index_read: failed (-30989)
> <= bdb_equality_candidates: id=0, first=0, last=0
> => bdb_equality_candidates (sAMAccountName)
> => key_read
> <= bdb_index_read 1 candidates
> <= bdb_equality_candidates: id=1, first=44, last=44
> bdb_search_candidates: id=1 first=44 last=44
> send_ldap_result: conn=8 op=2 p=3
> <==slap_sasl2dn: Converted SASL name to cn=ldapmaster,ou=domain
> controllers,dc=ldap,dc=local,dc=site
> slap_sasl_getdn: dn:id converted to cn=ldapmaster,ou=domain
> controllers,dc=ldap,dc=local,dc=site
> => hdb_search
> bdb_dn2entry("cn=ldapmaster,ou=domain
> controllers,dc=ldap,dc=local,dc=site")
> slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type undefined
> send_ldap_result: conn=8 op=2 p=3
> SASL [conn=8] Failure: no secret in database
> ---------------------------------
>
> the sasl2dn conversion looks allright for me;
> maybe this is the most intersting part:
> --->  bdb_dn2entry("cn=ldapmaster,ou=domain
> controllers,dc=ldap,dc=local,dc=site") <---
> ---> slap_ap_lookup: str2ad(cmusaslsecretDIGEST-MD5): attribute type
> undefined  <----
>
> any ideas?
>
> greetings,
> oliver
>
>
>
>
>
>

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 18.4610 from 23.07.2008
Virus news: www.antiviruslab.com

[Andrew Bartlett]

On Wed, 2008-07-23 at 15:00 +0200, Oliver Liebel wrote:
> hi andrew,
>
> i had just setup samba4 alpha5 with openldap 2.4.10, using the following
> configuration:

Can you use a current GIT snapshot?  The changed documentation in the
wiki represents the changes in the current GIT tree (I should make that
clear).

Andrew Bartlett

--
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com

[Oliver Liebel]

i tried to setup latest samba4 version from git with ol 2.4.11
and ran into some trouble during provisioning.
following the steps in the wiki -as andrew mentioned below-
the provision-backend script runs ok with the following directives:

#> setup/provision-backend --realm=local.site --domain=local
--ldap-admin-pass=linux
--ldap-backend-type=openldap --server-role='domain controller'
....
Converted 536 records (skipped 13) with 0 failures
Your openldap Backend for Samba4 is now configured, and is ready to be
started
Server Role:         domain controller
Hostname:            ldapmaster
DNS Domain:          local.site
Base DN:             DC=local,DC=site
LDAP admin user:     samba-admin
LDAP admin password: linux
Start slapd with:    slapd -f /usr/local/samba/private/ldap/slapd.conf
-h ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi
....

next starting slapd in debug mode, everything ok.

the final provisioning works only if the
<--simple-bind-dn="cn=samba-admin,cn=samba">  option is set, otherwise
an authentication error rises:
(ldb.LdbError: (8, 'LDAP error 8 LDAP_STRONG_AUTH_REQUIRED -  
<modifications require authentication> <>')

using the following settings:
#> setup/provision --realm=local.site --domain=local --adminpass=linux
--ldap-backend-type=openldap --ldap-backend=ldapi --server-role='domain
controller'
--simple-bind-dn="cn=samba-admin,cn=samba" --password=linux
....
Server Role:    domain controller
Hostname:       ldapmaster
NetBIOS Domain: LOCAL
DNS Domain:     local.site
DOMAIN SID:     S-1-5-21-924630919-2254292606-675636976
Admin password: linux
....

everything seems to work so far, but after setting up dns,krb and
starting smbd (-i -d 4)
i got the following errors:
....
ldb: pdc_fsmo_init: no domain object present: (skip loading of domain
details)
ldb: schema_fsmo_init: no schema head present: (skip schema loading)
ldb: naming_fsmo_init: no partitions dn present: (skip loading of naming
contexts details)
ldb: pdc_fsmo_init: no domain object present: (skip loading of domain
details)
Searching for fSMORoleOwner in DC=local,DC=site failed: LDAP error 32
LDAP_NO_SUCH_OBJECT -  <> <>
Failed to find if we are the PDC for this ldb
Failed to find our own NTDS Settings objectGUID in the ldb!
....

and i cant access the dit anyway.



the next point:
in the auto-generated slapd.conf there are several rootdn used
(for the subcontexts user,config,schema), which is ok so far.
but the rootdn  cn=Manager,cn=Samba  is the
rootdn for ...what? and is it ok that there is no corresponding rootpw
at all?
during provisioning, the object
LDAP admin user:     samba-admin
is created, and seems only to be used with the refint_modifiersname
(regarding to the thread "memberOf search ACLs" between andrew bartlett
an pierangelo masarati)


maybe i got the wrong view, but the provisioning-options
(--adminpass, --password, --simple-bind-dn)
in conjunction with the used rootdns  seems to me a little bit confusing.

greetings,
oliver























Andrew Bartlett schrieb:

> On Wed, 2008-07-23 at 15:00 +0200, Oliver Liebel wrote:
>  
>> hi andrew,
>>
>> i had just setup samba4 alpha5 with openldap 2.4.10, using the following
>> configuration:
>>    
>
> Can you use a current GIT snapshot?  The changed documentation in the
> wiki represents the changes in the current GIT tree (I should make that
> clear).
>
> Andrew Bartlett
>
>  

____________
Virus checked by G DATA AntiVirusKit
Version: AVK 18.4617 from 24.07.2008
Virus news: www.antiviruslab.com

[Andrew Bartlett]

On Thu, 2008-07-24 at 12:22 +0200, Oliver Liebel wrote:

> i tried to setup latest samba4 version from git with ol 2.4.11
> and ran into some trouble during provisioning.
> following the steps in the wiki -as andrew mentioned below-
> the provision-backend script runs ok with the following directives:
>
> #> setup/provision-backend --realm=local.site --domain=local
> --ldap-admin-pass=linux
> --ldap-backend-type=openldap --server-role='domain controller'
> ....
> Converted 536 records (skipped 13) with 0 failures
> Your openldap Backend for Samba4 is now configured, and is ready to be
> started
> Server Role:         domain controller
> Hostname:            ldapmaster
> DNS Domain:          local.site
> Base DN:             DC=local,DC=site
> LDAP admin user:     samba-admin
> LDAP admin password: linux
> Start slapd with:    slapd -f /usr/local/samba/private/ldap/slapd.conf
> -h ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi
> ....
>
> next starting slapd in debug mode, everything ok.
>
> the final provisioning works only if the
> <--simple-bind-dn="cn=samba-admin,cn=samba">  option is set, otherwise
> an authentication error rises:
> (ldb.LdbError: (8, 'LDAP error 8 LDAP_STRONG_AUTH_REQUIRED -  
> <modifications require authentication> <>')

You should specify --username=samba-admin.  This will then allow a SASL
bind, but it seems OpenLDAP is being flexible today, so it seemed to
work.  However, as I mention below, I think this is the cause of your
problems.

> using the following settings:
> #> setup/provision --realm=local.site --domain=local --adminpass=linux
> --ldap-backend-type=openldap --ldap-backend=ldapi --server-role='domain
> controller'
> --simple-bind-dn="cn=samba-admin,cn=samba" --password=linux
> ....
> Server Role:    domain controller
> Hostname:       ldapmaster
> NetBIOS Domain: LOCAL
> DNS Domain:     local.site
> DOMAIN SID:     S-1-5-21-924630919-2254292606-675636976
> Admin password: linux
> ....
>
> everything seems to work so far, but after setting up dns,krb and
> starting smbd (-i -d 4)
> i got the following errors:
> ....
> ldb: pdc_fsmo_init: no domain object present: (skip loading of domain
> details)
> ldb: schema_fsmo_init: no schema head present: (skip schema loading)
> ldb: naming_fsmo_init: no partitions dn present: (skip loading of naming
> contexts details)
> ldb: pdc_fsmo_init: no domain object present: (skip loading of domain
> details)
> Searching for fSMORoleOwner in DC=local,DC=site failed: LDAP error 32
> LDAP_NO_SUCH_OBJECT -  <> <>
> Failed to find if we are the PDC for this ldb
> Failed to find our own NTDS Settings objectGUID in the ldb!
> ....
>
> and i cant access the dit anyway.

This is odd, but quite possibly related to you using --simple-bind-dn
rather than --username (as the settings used for the provision are
recorded for long-term use, but the test scripts only hit the preferred
option, being --username).

> the next point:
> in the auto-generated slapd.conf there are several rootdn used
> (for the subcontexts user,config,schema), which is ok so far.
> but the rootdn  cn=Manager,cn=Samba  is the
> rootdn for ...what? and is it ok that there is no corresponding rootpw
> at all?

correct.  I wanted to move away from having the administrator password
clear in the config file.  We use the samba-admin account instead.

> during provisioning, the object
> LDAP admin user:     samba-admin
> is created, and seems only to be used with the refint_modifiersname
> (regarding to the thread "memberOf search ACLs" between andrew bartlett
> an pierangelo masarati)
>
>
> maybe i got the wrong view, but the provisioning-options
> (--adminpass, --password, --simple-bind-dn)
> in conjunction with the used rootdns  seems to me a little bit confusing.

--adminpass sets the "Administrator" password for that account.
--password is confusing, I agree, but sets the password that the
provision script should use to talk to the backend.  --simple-bind-dn
and --username both set the credentials to use with that password.

I considered changing this again, to use --authentication-file=<a file
generated by provision-backend>, so administrators only have the 'right'
choice' available, and your feedback confirms this.  

Please re-run your provision, using --username=samba-admin, and things
should be better.

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.

[Andrew Bartlett]

On Fri, 2008-07-25 at 17:12 +1000, Andrew Bartlett wrote:

> Please re-run your provision, using --username=samba-admin, and things
> should be better.

While I've not yet moved to the authentication file (partly because it
would then sit in the private folder forever, and be confused with the
real record in secrets.ldb), I have tried to make this clearer in the
provision-backend script.  Perhaps re-run that from current GIT and see
if it is clearer.

Thanks,

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.                  http://redhat.com