[Samba] Users unable to reset passwords
Mark Foley
mfoley at novatec-inc.com
Sun May 18 15:43:17 UTC 2025
On Sun May 18 03:22:40 2025 Penny via samba <samba at lists.samba.org> wrote:
>
> 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
That looks like a build script for a slackpkg. If plan B fails I'll revisit Plan
A and possibly try this.
>
> 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
Wow! Thanks for that! I'll use that on my next attempt.
> > 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.
I provisioned with the internal DNS, so I thought that would "magically" just
work. Perhaps some of the configure options you suggested would help.
> > # 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.
OK, thanks. I've corrected my documentation.
> > # 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 ?
In the current running AD there are lots of libnss files and links. I believe
the system is configure to use them. I'll check the "new" system after the next
build.
> Does /etc/nsswitch.conf havw 'winbind' in the 'passwd' & 'group' lines ?
YES.
> > 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.
I may try that after "Plan B".
> If you must stick with Slackware, then build it correctly.
Trying to do that.
> Rowland
I was not able to post this question for a couple of days due to
samba at lists.samba.org being down, so I moved on to plan B:
building/installing Samba on a clean system. I've already wiped and installed a
new Slackware and next will be to configure, install and provision Samba. I'll
use your suggested configure settings. I Will resume that effort tomorrow.
At this point, that's basically the same effort as provisioning Debian, but I'm
familiar with that process on Slackware. If that fails, or if it succeeds, but
the password/redirection problems still exits, I will go ahead and try the
Debian idea.
THX --Mark
More information about the samba
mailing list