samba - Sep 2022 - Problems with Samba after upgrading to v4 and changing LDAP-backend from OpenLDAP to 389

Hi,

I was wondering if anyone ran into the same issue and maybe has a solution for
me. In short:

- we were running SLES 11 with Samba 3.6.3 as NT4 PDC and OpenLDAP backend:
working fine
- we upgraded to SLES 15 with Samba 4.13.13 as NT4 PDC and old OpenLDAP backend:
working fine
- now we migrated from OpenLDAP to 389 and things start to break

LDAP seems to work in principle "pdbedit -L? is successful. However,
running ?pdbedit -Lv username? returns an error: ?Failed to find a Unix account
for username? and ?Primary Group SID: (NULL SID)?.

So I guess the idmap is messed up?

Actually I?m not sure how the idmap is stored in LDAP since both idmap-OUs look
the same to me (empty) on the old OpenLDAP and new 389.

Any hints/advice?

Thanks

On 21/09/2022 10:57, Alexander Harm || ApfelQ via samba
wrote:
> Hi,
> 
> I was wondering if anyone ran into the same issue and maybe has a solution
for me. In short:
> 
> - we were running SLES 11 with Samba 3.6.3 as NT4 PDC and OpenLDAP backend:
working fine
> - we upgraded to SLES 15 with Samba 4.13.13 as NT4 PDC and old OpenLDAP
backend: working fine
Why did you upgrade a PDC to another PDC ?
Why didn't you upgrade to AD ?
An NT4-style domain relies on SMBv1 and Samba is working hard to remove 
SMBv1, so you may get this working again, but it will only be a short 
term fix.
> - now we migrated from OpenLDAP to 389 and things start to break
Why upgrade something that works to an unknown quantity, 389 is very 
different to Openldap.

> 
> LDAP seems to work in principle "pdbedit -L? is successful. However,
running ?pdbedit -Lv username? returns an error: ?Failed to find a Unix account
for username? and ?Primary Group SID: (NULL SID)?.
> 
> So I guess the idmap is messed up?
> 
> Actually I?m not sure how the idmap is stored in LDAP since both idmap-OUs
look the same to me (empty) on the old OpenLDAP and new 389.
> 
Samba may not be using ldap, can we please see your smb.conf

Rowland

Hello Alexander,

On 2022-09-21 at 11:57 +0200 Alexander Harm || ApfelQ via samba sent
off:
> LDAP seems to work in principle "pdbedit -L? is successful. However,
running ?pdbedit -Lv username? returns an error: ?Failed to find a Unix account
for username? and ?Primary Group SID: (NULL SID)?.
> 
> So I guess the idmap is messed up?
> 
> Actually I?m not sure how the idmap is stored in LDAP since both idmap-OUs
look the same to me (empty) on the old OpenLDAP and new 389.
> 
> Any hints/advice?
the old non-OpenLDAP schema files might not be as up-to-date as the OpenLDAP
schema file is. We had a focus mainly on the OpenLDAP support in the past and
the Netscape schema files had missed updated sometimes. Or the schema extension
is not correctly installed on your 389 server.

Best regards
Bj?rn
-- 
SerNet GmbH - Bahnhofsallee 1b - 37081 G?ttingen
phone: +495513700000  mailto:contact at sernet.com
AG G?ttingen: HR-B 2816 - https://www.sernet.com
Manag. Directors Johannes Loxen and Reinhild Jung
data privacy policy https://www.sernet.de/privacy

On Wed, 2022-09-21 at 11:57 +0200, Alexander Harm || ApfelQ via samba
wrote:
> Hi,
> 
> I was wondering if anyone ran into the same issue and maybe has a
> solution for me. In short:
> 
> - we were running SLES 11 with Samba 3.6.3 as NT4 PDC and OpenLDAP
> backend: working fine
> - we upgraded to SLES 15 with Samba 4.13.13 as NT4 PDC and old
> OpenLDAP backend: working fine
> - now we migrated from OpenLDAP to 389 and things start to break
> 
> LDAP seems to work in principle "pdbedit -L? is successful. However,
> running ?pdbedit -Lv username? returns an error: ?Failed to find a
> Unix account for username? and ?Primary Group SID: (NULL SID)?.
> 
> So I guess the idmap is messed up?
Looping back to the start, I think you a suggested elsewhere in the
thread need to work on this one step at a time.

I agree that getting OpenLDAP back, if a reverse migration is possible,
at least in a lab, might be a good idea, and confirm that the issue
really is with OpenLDAP and not something else.

'Clearly' something is different about the 389 LDAP server vs
OpenLDAP. 

Do they both accept the same (non)authentication?

You should be able to debug this with either a network capture, or LDAP
comparison tools.  (I don't know if Samba's samba-tool ldapcmp can do a
good enough job, but try it using the --simple-bind-dn mode). 

Try dumping a sorted LDIF of each directory, and compare with diff
even. 

Try turning up the log level and see what errors you see compared with
your old OpenLDAP.

Then finally, think about a migration to Samba AD, and how to have your
other applications work with AD or synchronise with it.  This is a much
longer term project. 
> Actually I?m not sure how the idmap is stored in LDAP since both
> idmap-OUs look the same to me (empty) on the old OpenLDAP and new
> 389.
> 
> Any hints/advice?
Try not to change too much at once, particularly around idmap. 

Andrew Bartlett

-- 
Andrew Bartlett (he/him)       https://samba.org/~abartlet/
Samba Team Member (since 2001) https://samba.org
Samba Team Lead, Catalyst IT   https://catalyst.net.nz/services/samba

Samba Development and Support, Catalyst IT - Expert Open Source
Solutions