samba with openldap provisioning

Mon Aug 26 13:21:33 MDT 2013

A bit of an update - I was able to successfully provision with alpha 13,
but alpha 14 failed in the same way, so the villain is hidden in between,
I'll keep looking...

On Sun, Aug 25, 2013 at 8:59 PM, Nadezhda Ivanova <nivanova at samba.org>wrote:

> Hi Andrew,
> I need some more advice - it appears that provisioning fails because we
> cannot do a sasl bind, here i what appears in the log:
> .
> .
> .
>
>
> Successfully loaded vfs module [acl_xattr] with the new modules system
> Initialising custom vfs hooks from [dfs_samba4]
> Successfully loaded vfs module [dfs_samba4] with the new modules system
> connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and
> 'force unknown acl user = true' for service Unknown Service (snum == -1)
> config file testing succeeded
> lpcfg_servicenumber: couldn't find ldb
> Failed to inquire of target's available sasl mechs in rootdse search:
> NT_STATUS_UNEXPECTED_NETWORK_ERROR
> Failed to bind - LDAP client internal error:
> NT_STATUS_UNEXPECTED_NETWORK_ERROR
> Failed to connect to
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' with backend
> 'ldapi': (null)
> lpcfg_servicenumber: couldn't find ldb
> Failed to inquire of target's available sasl mechs in rootdse search:
> NT_STATUS_UNEXPECTED_NETWORK_ERROR
> Failed to bind - LDAP client internal error:
> NT_STATUS_UNEXPECTED_NETWORK_ERROR
> Failed to connect to
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' with backend
> 'ldapi': (null)
> lpcfg_servicenumber: couldn't find ldb
> GENSEC backend 'gssapi_spnego' registered
> GENSEC backend 'gssapi_krb5' registered
> GENSEC backend 'gssapi_krb5_sasl' registered
> GENSEC backend 'sasl-DIGEST-MD5' registered
> GENSEC backend 'schannel' registered
> GENSEC backend 'spnego' registered
> GENSEC backend 'ntlmssp' registered
> GENSEC backend 'krb5' registered
> GENSEC backend 'fake_gssapi_krb5' registered
> Starting GENSEC mechanism ntlmssp
> Got challenge flags:
> Got NTLMSSP neg_flags=0x00028205
>   NTLMSSP_NEGOTIATE_UNICODE
>   NTLMSSP_REQUEST_TARGET
>   NTLMSSP_NEGOTIATE_NTLM
>   NTLMSSP_NEGOTIATE_ALWAYS_SIGN
> Server did not provide 'target information', required for NTLMv2
> Failed to bind - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
> Failed to connect to
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' with backend
> 'ldapi': (null)
> .
> .
> .
> Could not connect to slapd started with: '/usr/local/libexec/slapd'
> '-F/usr/local/samba/private/ldap/slapd.d' '-h'
> 'ldapi://%2Fusr%2Flocal%2Fsamba%2Fprivate%2Fldap%2Fldapi' '-d0'
> ERROR(<class 'samba.provision.ProvisioningError'>): Provision failed -
> ProvisioningError: slapd never accepted a connection within 15 seconds of
> starting
>   File
> "/usr/local/samba/lib/python2.7/site-packages/samba/netcmd/domain.py", line
> 400, in run
>     use_rfc2307=use_rfc2307, skip_sysvolacl=False)
>   File
> "/usr/local/samba/lib/python2.7/site-packages/samba/provision/__init__.py",
> line 2093, in provision
>     provision_backend.start()
>   File
> "/usr/local/samba/lib/python2.7/site-packages/samba/provision/backend.py",
> line 302, in start
>     raise ProvisioningError("slapd never accepted a connection within 15
> seconds of starting")
>
>
>
> The first 2 NT_STATUS_UNEXPECTED_NETWORK_ERROR messages are not a problem,
> slapd is not yet functioning and they go away if I add a sleep before the
> first attempt.
> This is what is interesting in the slapd log if I run it with -d16
>
> ber_dump: buf=0x7fd6f4100f00 ptr=0x7fd6f4100f00 end=0x7fd6f4100f45 len=69
>   0000:  02 01 02 60 40 02 01 03  04 00 a3 39 04 04 4e 54
> ...`@......9..NT
>   0010:  4c 4d 04 31 4e 54 4c 4d  53 53 50 00 01 00 00 00
> LM.1NTLMSSP.....
>   0020:  05 82 08 60 0a 00 0a 00  20 00 00 00 07 00 07 00   ...`....
> .......
>   0030:  2a 00 00 00 54 45 53 54  44 4f 4d 41 49 4e 44 52
> *...TESTDOMAINDR
>   0040:  49 5a 5a 49 54
> IZZIT
> ber_dump: buf=0x7fd6f4100f00 ptr=0x7fd6f4100f03 end=0x7fd6f4100f45 len=66
>   0000:  60 40 02 01 03 04 00 a3  39 04 04 4e 54 4c 4d 04
> `@......9..NTLM.
>   0010:  31 4e 54 4c 4d 53 53 50  00 01 00 00 00 05 82 08
> 1NTLMSSP........
>   0020:  60 0a 00 0a 00 20 00 00  00 07 00 07 00 2a 00 00   `....
> .......*..
>   0030:  00 54 45 53 54 44 4f 4d  41 49 4e 44 52 49 5a 5a
> .TESTDOMAINDRIZZ
>   0040:  49 54
> IT
> ber_dump: buf=0x7fd6f4100f00 ptr=0x7fd6f4100f0a end=0x7fd6f4100f45 len=59
>   0000:  00 39 04 04 4e 54 4c 4d  04 31 4e 54 4c 4d 53 53
> .9..NTLM.1NTLMSS
>   0010:  50 00 01 00 00 00 05 82  08 60 0a 00 0a 00 20 00   P........`....
> .
>   0020:  00 00 07 00 07 00 2a 00  00 00 54 45 53 54 44 4f
> ......*...TESTDO
>   0030:  4d 41 49 4e 44 52 49 5a  5a 49 54
> MAINDRIZZIT
> ber_dump: buf=0x7fd6f4100f00 ptr=0x7fd6f4100f12 end=0x7fd6f4100f45 len=51
>   0000:  00 31 4e 54 4c 4d 53 53  50 00 01 00 00 00 05 82
> .1NTLMSSP.......
>   0010:  08 60 0a 00 0a 00 20 00  00 00 07 00 07 00 2a 00   .`....
> .......*.
>   0020:  00 00 54 45 53 54 44 4f  4d 41 49 4e 44 52 49 5a
> ..TESTDOMAINDRIZ
>   0030:  5a 49 54
> ZIT
> ber_dump: buf=0x7fd6f4100f00 ptr=0x7fd6f4100f45 end=0x7fd6f4100f45 len=0
>
>   0000:  30 81 8d 02 01 02 61 81  87 0a 01 0e 04 00 04 40
> 0.....a........@
>   0010:  53 41 53 4c 28 30 29 3a  20 73 75 63 63 65 73 73   SASL(0):
> success
>   0020:  66 75 6c 20 72 65 73 75  6c 74 3a 20 73 65 63 75   ful result:
> secu
>   0030:  72 69 74 79 20 66 6c 61  67 73 20 64 6f 20 6e 6f   rity flags do
> no
>   0040:  74 20 6d 61 74 63 68 20  72 65 71 75 69 72 65 64   t match
> required
>   0050:  87 3e 4e 54 4c 4d 53 53  50 00 02 00 00 00 0e 00
> .>NTLMSSP.......
>   0060:  0e 00 30 00 00 00 05 82  02 00 aa 40 df 77 88 1a   ..0........ at .w..
>
>   0070:  13 7b 00 00 00 00 00 00  00 00 00 00 00 00 00 00
> .{..............
>   0080:  00 00 44 00 52 00 49 00  5a 00 5a 00 49 00 54 00
> ..D.R.I.Z.Z.I.T.
>
>
> An ldapsearch with sasl authentication works fine, although in this case I
> did not find anything in the slapd log to see what the difference is.
> Have you seen this before,any ideas how to debug it?
>
>
> Regards,
> Nadya
>
>
> On Fri, Aug 2, 2013 at 3:08 AM, Andrew Bartlett <abartlet at samba.org>wrote:
>
>> On Fri, 2013-08-02 at 11:15 +1200, Andrew Bartlett wrote:
>> > On Thu, 2013-08-01 at 12:53 +0300, Nadezhda Ivanova wrote:
>> > > Hi Andrew,
>> > > I've been trying to provision samba to use openldap backend, but have
>> > > been unsuccessful so far, and as there are no error messages, I am not
>> > > sure if I am doing something wrong or it is a bug introduced after
>> > > development was discontinued. The howto has been removed from the
>> > > wiki. I have a working installation of OpenLDAP - installed but not
>> > > running (running or not, it seems to make no difference). I was unable
>> > > to find if some special openldap configuration was needed, so I only
>> > > have one database configured for my domain.
>> > >
>> > > This is my command line:
>> > >
>> > > /usr/local/samba/bin/samba-tool domain provision --use-rfc2307
>> > > --realm=nadya.com --domain=testdomain --host-name=drizzit
>> > > --host-ip=127.0.0.1 --adminpass=Secret123 --root=root
>> > > --server-role="domain controller" --ldapadminpass=secret
>> > > --ldap-backend-type=openldap -d 7
>> >
>> > Try reverting 2b50e8c534872117e7687d643dd8a849e8c044d7 and then adding
>> > --slapd-path=/usr/sbin/slapd
>> >
>> > Or run:
>> >
>> > OPENLDAP_SLAPD=/usr/sbin/slapd TEST_LDAP=yes make quicktest
>> >
>> > > Any ideas?
>> >
>> > Beyond that, looking over the git log for other things I may have done
>> > to lay landmines in your path, or following the script though with some
>> > "print" debugging might help.
>> >
>> > I'm also very glad to help out, so keep up the mail!
>> >
>> > Thanks, and good luck!
>>
>> You may also wish to revert 696a70c9faac27bcd473b6c2f1444abd267ae6e6 to
>> get back some other options that we had here.
>>
>> Andrew Bartlett
>>
>>
>> --
>> Andrew Bartlett
>> http://samba.org/~abartlet/
>> Authentication Developer, Samba Team           http://samba.org
>> Samba Developer, Catalyst IT                   http://catalyst.net.nz
>>
>>
>>
>