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

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

Hi Rowland,

I guess mainly for historical reasons and using LDAP-backend for phletora of
other applications which rely on ?userPassword?. OpenLDAP and support was
unfortunately removed from SLES.

Our smb.conf:

[global]
workgroup = EXAMPLE
server string = Samba (PDC) auf Brazilia
passdb backend = ldapsam:ldap://ldap1.example.com
ldap admin dn = cn=samba,ou=DSA,dc=example,dc=com
ldap ssl = start tls
ldap suffix = dc=example,dc=com
ldap user suffix = ou=people
ldap group suffix = ou=group
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
idmap uid = 15000-20000
idmap gid = 15000-20000
idmap backend = ldap:ldap://ldap1.example.com
wins support = Yes
name resolve order = host bcast
domain logons = Yes
domain master = Yes
local master = Yes
os level = 65
preferred master = Yes
security = user
server schannel = Yes
client ipc signing = auto
ldap passwd sync = Only
unix password sync = No
logon path logon drive = E:
printing = cups
printcap name = cups
printcap cache time = 750
cups options = raw
map to guest = Bad User
syslog = 0
log file = /var/log/samba/%m
include = /etc/samba/smb.conf.%m
encrypt passwords = yes
ldap delete dn = no
passwd program = /usr/sbin/smbldap-passwd -u %u
add user script = /usr/sbin/smbldap-useradd -m "%u"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u"
"%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u"
"%g"
delete user script = /usr/sbin/smbldap-userdel "%u"
rename user script = /usr/sbin/smbldap-usermod -r "%unew"
"%uold"
add group script = /usr/sbin/smbldap-groupadd '%g'
add machine script = /usr/sbin/smbldap-useradd -t 0 -w "%u"
set primary group script = /usr/sbin/smbldap-usermod -g "%g"
"%u"
netbios name = brazilia
ntlm auth = no

[netlogon]
comment = Netlogon Scripts
path = /server/data/samba/netlogon
read only = No
inherit acls = Yes
browseable = yes
guest ok = yes
printable = no
map archive = no
map read only = no
store dos attributes = yes

Thanks for your insights.
> On Wednesday, Sep 21, 2022 at 12:27 PM, Rowland Penny via samba <samba
at lists.samba.org (mailto:samba at lists.samba.org)> wrote:
>
>
> 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
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba