[Samba] Users unable to reset passwords

Rowland Penny rpenny at samba.org
Sun May 18 07:21:59 UTC 2025


On Sat, 17 May 2025 00:46:20 -0400
Mark Foley via samba <samba at lists.samba.org> wrote:

> I'm trying to solve a couple of problems with Samba 4.18.19 and
> Windows 11. I've described these in detail in previous messages in
> this thread, so I'll be brief here:
> 
> 1.  Not all users get notified of password expiration and in any
> case, if they permit their passwords to expire they cannot reset with
> the "reset password" dialog.  I have to do so with samba-tool. 
> 
> 2. The Redirected Folder Policy does not work.
> 
> Both of these features worked fine with Samba 4.8.2 and Windows 10.
> 
> I am running Slackware 15.0 and although I've been encouraged to move
> on to Debian, I've been running Samba as AD/DC on Slackware for 11
> years without actual problem, so I'll see what I can do before
> abandoning that ship.
> 
> I'm going to test 3 ways:
> 
> A. I will upgrade Samba to the latest 4.22.1, downloaded from
> samba.org, but keeping all the domain users, group, policies, etc.
> 
> B. If that doesn't work I will wipe the system and install and
> provision 4.22.1 from scratch.
> 
> C. If that doesn't work I will stage an actual Windows DC and see if
> the problem exists on that platform.
> 
> If B does not work but C does, I'll file a bug report for Samba. Then
> I'll have to decide whether I want to live with the
> password/redirected-folders issues on Samba or go with Windows. My
> inclination is to stick with Samba anyway as its better security and
> normally easier management is why I went with Samba over Windows 11
> years ago.
> 
> Results thus far:
> 
> Plan A
> 
> Slackware Samaba uses MIT Kerberos, but my installation of that was
> too old for Samba 4.22.1 so I switched to Heimdal (I think). After
> researching what went where my configure options were:
> 
> ./configure --prefix /var/lib/samba/ --sbindir=/usr/sbin/ \
>   --sysconfdir=/etc/samba/ --without-systemd --bindir=/usr/bin
> --disable-cups

I did say that building Samba for a distro was a bit more involved than
what you were proposing and that, in my opinion, still wasn't enough. A
quick internet search led me here:

https://slackware.uk/slackware/slackware64-15.0/source/n/samba/samba.SlackBuild

I think this would have been a lot nearer:

./configure \
  --enable-fhs \
  --prefix=/usr \
  --libdir=/usr/lib64 \
  --includedir=/usr/include \
  --bindir=/usr/bin \
  --sbindir=/usr/sbin \
  --mandir=/usr/man \
  --sysconfdir=/etc \
  --with-configdir=/etc/samba \
  --with-piddir=/var/run \
  --with-privatedir=/var/lib/samba/private \
  --with-privatelibdir=/usr/lib64 \
  --with-modulesdir=/usr/lib64 \
  --with-lockdir=/var/cache/samba \
  --with-logfilebase=/var/log/samba \
  --localstatedir=/var \
  --enable-cups \
  --with-acl-support \
  --with-automount \
  --with-quotas \
  --with-syslog \
  --with-utmp \
  --with-winbind \
  --with-ldap \
  --with-ads \
  --without-fam \
  --with-pam \
  --with-pammodulesdir=/lib64/security \
  --build=x86_64-slackware-linux || exit 1

> 
> Testing on Plan A gives mixed results. Testing per "Verifying the
> File Server":
> https://wiki.samba.org/index.php/Setting_up_Samba_as_an_Active_Directory_Domain_Controller#Verifying_the_File_Server_(Optional)
> gives:
> 
> # smbclient -L localhost -N
> Anonymous login successful
> 
>         Sharename       Type      Comment
>         ---------       ----      -------
>         Users           Disk      user folders for redirection
>         sysvol          Disk      
>         netlogon        Disk      
>         IPC$            IPC       IPC Service (Samba 4.22.1)
> SMB1 disabled -- no workgroup available
> 
> # smbclient //localhost/netlogon -UAdministrator -c 'ls'
>   .                                   D        0  Thu Jan 18 21:51:48
> 2024 ..                                  D        0  Thu Jan 18
> 21:51:48 2024
> 
>                 1913467748 blocks of size 1024. 1792046828 blocks
> available
> 
> Verifying DNS (Optional)
> 
> # host -t SRV _ldap._tcp.hprs.local.
> Host _ldap._tcp.hprs.local. not found: 3(NXDOMAIN)

You undoubtedly have a dns problem.
 
> 
> # host -t SRV _kerberos._udp.mail.hprs.local.
> Host _kerberos._udp.mail.hprs.local. not found: 3(NXDOMAIN)

If your dns was working, you would still need to remove 'mail' from
that before it would work.

> 
> # host -t A mail.hprs.local.
> Host mail.hprs.local. not found: 3(NXDOMAIN)
> 
> # host -t PTR 192.168.0.2
> Host 2.0.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
> 
> # kinit administrator
> kinit: Cannot find KDC for realm "HPRS.LOCAL" while getting initial
> credentials

Again, a dns problem.

> 
> # klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: administrator at HPRS.LOCAL
> 
> Valid starting       Expires              Service principal
> 05/07/2025 14:11:16  05/08/2025 00:11:16  krbtgt/HPRS.LOCAL at HPRS.LOCAL
>         renew until 05/08/2025 14:11:10
> 
> So, a few things. Maybe I need to forget plan A and got to plan B.
> 
> It looks like the smbclient things worked, but none of the verifying
> DNS tests worked. The IP for mail.hprs.local isn't found, yet the
> list of A records does show it at 192.168.0.2.
> 
> I initially provisioned with --dns-backend=SAMBA_INTERNAL
> 
> kinit fails, but klist appears to succeed.  Interestingly, the only
> kinit/klist on the system is /usr/bin/kinit and /usr/bin/klist, both
> dated Jul 12 2023, which I think is the old one from MIT Kerberos. 

If 'kinit' did fail, then there shouldn't be a kerberos cache for klist
to read, so it was either an old cache or kinit did work.

> 
> More:
> 
> wbinfo -u (does show all domain users)
> 
> wbinfo -g (does show all domain groups)
> 
> getent passwd mark (returns nothing)

Were the libnss-winbind links built and if so, is your distro set up to
use them ?

Does /etc/nsswitch.conf havw 'winbind' in the 'passwd' & 'group' lines ?

> 
> getent group Domain\ Users (returns nothing)
> 
> Is there something I'm not enabling, or should I just move on to plan
> B and scratch install and provision with Samba 4.22.1?
> 

I personally would just join a test Debian Samba DC and point a client
that has been having problems at it.

If you must stick with Slackware, then build it correctly.

Rowland



More information about the samba mailing list