LDIF import to openldap_15 fails

FWIW by my (somewhat limited) understanding you can replicate AD domain data via as many AD DCs as you like. So whilst the data isn't decoupled as you'd ideally like, it can be replicated, giving you the fault tolerance I assume you are hoping for.

Good luck with it all and please feel free to post back (regardless of success or failure). Whilst I'm not super experienced with Samba4 at a production level, I do have at least a reasonable theoretical understanding and have been involved in development and maintenance of our appliance. I also have pretty good google-fu! :)

Hi Jeremy,

Somebody on OpenLDAP tech mailing lists has confirmed that direct migrations between SambaLDAP and OpenLDAP require some additional steps.

I don't desperately need OpenLDAP for anything specific.
I just thought it would be nice to decouple it in a container and, apart from Samba Active Directory functions, use it for other things e.g. for authenticating pfSense OpenVPN users.

I have now deployed debian-9-turnkey-domain-controller_15 appliance and looking into migrating everything from an ageing and out of support Debian7/Samba 4.0.9 to Debian9/Samba 4.5.16 provided by this appliance.
I'll let you know how this went or maybe cry for help again if I get badly stuck on something :)

Thanks,
Adam

Although having said that, I may have some info of value to share.

As I understand it, unless you are running Samba as an NT style domain (i.e. configured as per Samba3 and not as an AD domain) LDAP as provided by Samba4 is not directly compatible with OpenLDAP. My understanding is that the Samba LDAP implementation includes data which OpenLDAP doesn't know what to do with (hence why I assume you are getting these errors).

Please see the relevant Samba FAQ here and here. As such, you'd need to use Samba to supply the LDAP (e.g. via our Domain Controller appliance), rather than OpenLDAP. If you wish to persist regardless, it seems that there has been some work in trying to make them compatible, this Samba Wiki page may be of interest?

Beyond what I've read, TBH I get a bit lost in LDAP. It's quite possible that I'm missing something, so please feel free to provide additional info and rationale on what you're trying to achieve and I'll do my best to help out.

But looking at those messages, it appears that the second one is failing to authenticate. According to google, that's the cause of it being instantly disconnected. I.e.: "stream_terminate_connection", "NT_STATUS_CONNECTION_DISCONNECTED".

I'm no Samba expert, but my first thought is time synchronisation. I know Kerberos is quite time sensitive (will refuse to authenticate if there is time difference between server and client), so I'd double check that the time is right on all servers and the client. FWIW here is the relevant Samba wiki page.

If you can confirm that's not the issue, then I can only recommend that you have a read through the Samba AD DC setup page. We used that as a reference when creating our config scripts, so it should all be good. But perhaps we missed something?

Feel free to post back with any further info you discover, although I'm not sure how useful I'll be...

Failing all that, I'd suggest that you sign up to the Samba mailing list and ask on there. FWIW TurnKey v15.x is based on Debian 9/Stretch and all the Samba components are installed directly from the Debian apt repos. Our config scripts leverage the Samba setup commands as noted above.

I hope that helps...

It'd be great to hear back how you go. Especially if you find something that we could be doing better!

I'm trying to make pfSense talk to Samba AD LDAP through "bind credentials to resolve distinguished names" option.

I have 2 accounts which, as far as I can tell, look identical from AD perspective.

One of them successfully connects (Samba logs):

[2019/06/12 14:34:41.517364,  3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect)
  ldb_wrap open of secrets.ldb
[2019/06/12 14:34:41.520731,  3] ../source4/auth/ntlm/auth.c:271(auth_check_password_send)
  auth_check_password_send: Checking password for unmapped user [MATRIX_SCIENCE]\[account1]@[(null)]
  auth_check_password_send: mapped user is: [MATRIX_SCIENCE]\[account1]@[(null)]
[2019/06/12 14:34:41.521510,  4] ../source4/auth/sam.c:183(authsam_account_ok)
  authsam_account_ok: Checking SMB password for user account1

The other one fails:

[2019/06/12 15:09:56.215000,  3] ../lib/ldb-samba/ldb_wrap.c:325(ldb_wrap_connect)
  ldb_wrap open of secrets.ldb
[2019/06/12 15:09:56.217871,  3] ../source4/smbd/service_stream.c:66(stream_terminate_connection)
  Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED'
[2019/06/12 15:09:56.217941,  3] ../source4/smbd/process_single.c:114(single_terminate)
  single_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_DISCONNECTED]

Any idea what the second account is missing?

The difference must be restricted to what's replicated between domain controllers as the behavior is identical against the primary and secondary one.

This is down to some subtle difference between these 2 accounts.

All credentials are valid as I can log in to the domain with both.

When I run "ldapsearch -D 'account@mydomian.co.uk' -b 'cn=Users,dc=mydomain,dc=co,dc=uk' -H ldap://dc15 -W sAMAccountName=account" the responses are successful and identical apart from these 2 lines:

msDS-SupportedEncryptionTypes: 0
msSFU30Name: account2

which only appear for the second (problematic) account.

I got authentication (bind credentials) working for account2 on the old DC (Samba 4.0.9):

CN=account1,CN=Users,DC=matrixscience,DC=co,DC=uk ---> OK
CN=account2,CN=Users,DC=matrixscience,DC=co,DC=uk ---> FAIL
MATRIXSCIENCE.CO.UK\account1 ---> OK
MATRIXSCIENCE.CO.UK\account2 ---> OK

but it's still failing on the new DC (Samba 4.5.16):

CN=account1,CN=Users,DC=matrixscience,DC=co,DC=uk ---> OK
CN=account2,CN=Users,DC=matrixscience,DC=co,DC=uk ---> FAIL
MATRIXSCIENCE.CO.UK\account1 ---> FAIL
MATRIXSCIENCE.CO.UK\account2 ---> FAIL

I suspected this might be due to some difference in smb.conf files on both controllers.
They are now almost identical to no joy and I'm running out of ideas...

[LDAP browser](http://directory.apache.org/studio/) helped a bit and allowed me to see a more specific error:

```
[LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1]
```
After a bit of research I've managed to connect using "account@domain.co.uk" format in "Bind credentials" username.

To recap the situation I'm in regarding "Bind credentials" and Samba DC versions:

**account@domain.co.uk**   ---> this works for both 4.0.9 and 4.5.16
**DOMAIN.CO.UK\account**   ---> this works for 4.0.9 but not 4.5.16
**CN=account,CN=Users,DC=domain,DC=co,DC=uk**   ---> this works for both 4.0.9 and 4.5.16 for some users but not for some others. I haven't been able to find a pattern and all test users look identical to me from AD perspective.

I can consider my issue solved but wouldn't mind getting to the bottom of it if anybody has any suggestions.