[Samba] Problems with Samba after upgrading to v4 and changing LDAP-backend from OpenLDAP to 389

Alexander Harm || ApfelQ alexander.harm at apfelq.com
Fri Sep 23 10:31:30 UTC 2022


I couldn’t help myself but dig some more. I compared the ldif as suggested and they are identical. From what I gather, the results that LDAP returns are fine but the process fails at a non-LDAP stage:

The LDAP server is successfully connected
pdb backend ldapsam:ldap://ldap1.example.com has a valid init
smbldap_search_ext: base => [dc=example,dc=com], filter => [(&(uid=johndoe)(objectclass=sambaSamAccount))], scope => [2]
init_sam_from_ldap: Entry found for user: johndoe
pdb_set_username: setting username johndoe, was
pdb_set_domain: setting domain EXAMPLE, was
pdb_set_nt_username: setting nt username johndoe, was
pdb_set_user_sid_from_string: setting user sid S-1-5-21-1926693724-44905045-1282156110-25724
pdb_set_user_sid: setting user sid S-1-5-21-1926693724-44905045-1282156110-25724
attribute sambaLogonTime does not exist
attribute sambaLogoffTime does not exist
attribute sambaPwdCanChange does not exist
pdb_set_full_name: setting full name Doe, John, was
pdb_set_dir_drive: setting dir drive E:, was NULL
pdb_set_homedir: setting home dir \\univers\homes, was
pdb_set_logon_script: setting logon script johndoe, was
attribute sambaProfilePath does not exist
pdb_set_profile_path: setting profile path , was
attribute description does not exist
attribute sambaUserWorkstations does not exist
attribute sambaMungedDial does not exist
attribute sambaLMPassword does not exist
Opening cache file at /var/lib/samba/lock/gencache.tdb
attribute sambaBadPasswordCount does not exist
attribute sambaBadPasswordTime does not exist
attribute sambaLogonHours does not exist
Opening cache file at /var/lib/samba/login_cache.tdb
Looking up login cache for user johndoe
No cache entry found
No cache entry, bad count = 0, bad time = 0
Finding user johndoe
Trying _Get_Pwnam(), username as lowercase is johndoe
Trying _Get_Pwnam(), username as uppercase is JOHNDOE
Checking combinations of 0 uppercase letters in johndoe
Get_Pwnam_internals didn't find user [johndoe]!
Failed to find a Unix account for johndoe
pdb_set_username: setting username johndoe, was
pdb_set_domain: setting domain EXAMPLE, was
pdb_set_nt_username: setting nt username johndoe, was
pdb_set_full_name: setting full name Doe, John, was
pdb_set_homedir: setting home dir \\univers\homes, was
pdb_set_dir_drive: setting dir drive E:, was NULL
pdb_set_logon_script: setting logon script johndoe, was
pdb_set_profile_path: setting profile path , was
pdb_set_workstations: setting workstations , was
pdb_set_user_sid: setting user sid S-1-5-21-1926693724-44905045-1282156110-25724
pdb_set_user_sid_from_rid:
setting user sid S-1-5-21-1926693724-44905045-1282156110-25724 from rid 25724
Unix username: johndoe
NT username: johndoe
Account Flags: [U ]
User SID: S-1-5-21-1926693724-44905045-1282156110-25724
Finding user johndoe
Trying _Get_Pwnam(), username as lowercase is johndoe
Trying _Get_Pwnam(), username as uppercase is JOHNDOE
Checking combinations of 0 uppercase letters in johndoe
Get_Pwnam_internals didn't find user [johndoe]!
Failed to find a Unix account for johndoe

So where the two differ are here:

Finding user johndoe
Trying _Get_Pwnam(), username as lowercase is johndoe
Trying _Get_Pwnam(), username as uppercase is JOHNDOE
Checking combinations of 0 uppercase letters in johndoe
Get_Pwnam_internals didn't find user [johndoe]!
Failed to find a Unix account for johndoe

and on the old server it just returns the user straight away. Is that a problem of PAM configuration?

Regards, Alexander

> On Wednesday, Sep 21, 2022 at 10:59 PM, Andrew Bartlett <abartlet at samba.org (mailto:abartlet at samba.org)> wrote:
> Great, sounds like you are taking things carefully. Also note that
> Symas provides OpenLDAP packages:
>
> https://repo.symas.com/soldap/
>
> https://www.symas.com/symas-download-software
>
> Andrew Bartlett
>
> On Wed, 2022-09-21 at 22:49 +0200, Alexander Harm || ApfelQ via samba
> wrote:
> > Thanks again and don’t worry. We did not blindly upgrade, we are
> > testing this in a clone of our production environment. So rolling
> > back etc. is not an issue right now. I will go through your
> > suggestions. Thank you all for your input.
> >
> > > On Wednesday, Sep 21, 2022 at 9:52 PM, Andrew Bartlett <
> > > abartlet at samba.org
> > > (mailto:
> > > abartlet at samba.org
> > > )> wrote:
> > >
> > > 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
> > >
> --
> 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
>


More information about the samba mailing list