Situation – TrueNAS (or FreeNAS, or other Samba servers) serving a SMB share with NTLMv1 authentication disabled. A standalone Windows 10 system can connect to it, but a domain joined Win 10 system constantly claims wrong password.
The culprit here was a old group policy setting in the domain:
Network Security: LAN Manager authentication level
Computer Configuration - Windows Settings - Security Settings - Local Policies - Security Options)
This was set to
Send LM & NTLM - use NTLMv2 session security if negotiated, for backwards compatibility reasons with Win 2000 boxes and the like. This affects the registry key
lmcompatibilitylevel (setting it to 1) under
Unfortunately this is a bit misleading. According to this article:
Security Watch: The Most Misunderstood Windows Security Setting of All Time
This should negotiate better session security if possible, but does not actually send NTLMv2 requests or responses.
Thus trying to connect to a TrueNAS SMB share fails unless NTLMv1 Auth is explicitly enabled (in the service settings).
Ideally the group policy should be removed and the normal setting restored (NTLMv2 only). Or we can enable NTLMv1 on the share if it isn’t going to be a permanent setup.
After updating anything to use systemd-235 NIS logins either don’t work at all (usually for GUI logins), or take a long time to login (console or ssh, sometimes). The culprit is a line in the
This sandboxes the service and doesn’t allow it to talk to the network. Unfortunately this affects nis lookups done via the glibc NSS API. See the links at https://github.com/systemd/systemd/pull/7343
The quick solution is to turn off the sandboxing, either by commenting out or changing the line in systemd-logind.service, or creating a drop-in snippet that overrides it. This can be done by creating a file
/etc/systemd/system/systemd-logind.service.d/IPAddress_clear.conf with the contents:
The file can be called anything you like (
Then restart things:
systemctl restart systemd-logind.service
You can check that the drop-in is being loaded with
systemctl status systemd-logind.service
In the output you should see something like:
Loaded: loaded (/lib/systemd/system/systemd-logind.service; static; vendor preset: enabled)
The other test is to see if NIS logins work correctly, of course…
The slightly slower solution is to use
nscd to cache the lookup requests, and apparently does so in a way that plays nicely with the sandboxing. The much slower solution is to switch to using
sssd or similar and ditch NIS once and for all…
Note – this may also affect
See the guide for 16.04, but with the following caveats:
Looks like you still need to add nis explicitly to
rpcbind service issue appears to be fixed.
Note – this only sets up the system to use user and group logons, not automounting home directories. I haven’t figured out how to make this work in Ubuntu 16.
Probably a good idea to set network address statically in
/etc/network/interfaces (NetworkManager should recognise this and then leave it alone)
Probably also a good idea to check that
/etc/hosts has the domain name for the system, i.e.
127.0.1.1 domain.name.machinename machinename
Add yp server to
/etc/nsswitch.conf to add nis for passwd, group and shadow. Note that compat should include nis by default.
Add a dependency to make the rpcbind service start at boot
systemctl add-wants multi-user.target rpcbind.service
(See this Debian bug report or this Ubuntu one)
Note that this is not a complete fix – it is reported that if the network does not come up fast enough things still break.
For users that need to log on to the system, create home directories
Remember to reboot to check everything is working:
if that fails check if the bind services are running
systemctl status rpcbind
systemctl status ypbind
The WordPress wpDirAuth plugin currently has a hard coded session time of 1 hour for directory authenticated (LDAP etc.) users. Hopefully at some point in the future this will become configurable. Discussion here.
On a related note, inserting
define( 'AUTOSAVE_INTERVAL', 60 ); // Seconds
in wp-config.php changes the autosave interval (default is 60 seconds).
Edit: Fixed in V1.9.3 thanks to patch submitted by Sean Leavey – time is now configurable.