Accessing Samba 4.11 shares from old clients, e.g. XP, Android apps, media players, etc

NB: Please do not do this if you are running a work network, as SMB1 has insecure authentication, and traffic is in clear. Get your clients updated. I did this only because I run Samba on a home network serving only a few of my applications, and only for legacy clients.

When I upgraded my Linux distro I discovered that starting with Samba 4.11 the minimum protocol support level has been raised to SMB2 by default. This made the shares I export inaccessible to an XP virtual machine driving a scanner and a chip programmer, and also an app on my Android tablet.

There are lots of confusing posts on the Internet some about older versions. This relates to these changes. You can still enable SMB1 support, using these lines in smb.conf:

min protocol = NT1
ntlm auth = Yes

Restart nmb and smb and the changes should take effect.

SMB1 support may be removed in future, so hopefully my applications will be also updated before then.

Login to standalone Samba server from Windows 7 (and above)

At a workplace we have a server in the DMZ running Samba and other things and therefore not joined to the Windows domain. It has a small set of local users (no, no, we would never share a CIFS over the Internet) whose passwords are managed with smbpasswd. When a user tries to connect to a Samba share, the Windows desktop "helpfully" prefills the login name as domain\username. The login fails because the Samba server is not in the domain. This did not happen in XP.

Extremely simple solution, opt to login as a different user and use:

\username

to login. For some reason this is not widely known. NET USE will also work but then the user has to use a COMMAND window.

It works for me and it also worked for this person.

Deploying SSSD for authentication against Windows AD in CentOS 6

In an earlier post I discussed in general terms deploying SSSD on CentOS 7 which is fairly straightforward once the right choices have been made.

I have now successfully deployed it on CentOS 6. This blog post by one of the authors of SSSD gave me the initial clues. The key point is that while sssd and associated packages are available on CentOS 6, realmd is not so you have to do those steps manually using adcli.

There was one big problem though, the join command didn't work for me! When it came to that step I got an error message saying I had insufficient permissions to modify the computer entry in AD. I tried various permutations but still got the same error.

Finally I decided to examine the progress messages of realm -v join on a CentOS 7 machine to see what it was doing under the hood. It turned out to be a command of this form:

net -s /tmp/sssd-smb.tmpfile ads join example.com

So it was using the Samba net command, not adcli for joining!

The temporary file providing the settings to net was of the form:

[global]
workgroup = EXAMPLE
netbios name = MYWORKSTATION-N
realm = EXAMPLE.COM
kerberos method = system keytab
security = ads

Note that the netbios name should be truncated to 15 characters. The reason net is used is explained in the last comment of this bug report.

Now I don't know if realm switched to calling net when it detected that adcli would not work, or uses net since that blog post was written, to satisfy servers that don't allow creation/modification of computer entries with LDAP. I think the latter because realmd comes from the CentOS repo while adcli comes from EPEL repo so can't be a dependency. I suppose I could look at the code.

The next command that realm runs is:

net -s /tmp/sssd-smb.tmpfile ads keytab create

Once that is done, you will be able to run klist -k and get output. Then follow the rest of the blog post to set up sssd. If you were running /etc/passwd authentication, remember to delete those entries in passwd, group, shadow, and gshadow so that they don't mask the user entries from AD. Restart nscd to flush any cached entries afterwards. In the long term you want to follow RedHat's recommendations referred to in my CentOS 7 blog post to disable nscd caching for user and group entries.

Dos and Don'ts deploying sssd for authentication against Windows AD

New: For deployment on Redhat/CentOS 6, see here.

sssd (and realmd) in RedHat/CentOS 7 offers the chance to use Windows as a single authentication base. The RedHat manual was the most useful but there were also good debugging tips on stackoverflow and similar forums. However in deploying sssd I found some things worked for me and some things didn't.

• Do harmonise all the Windows and Linux login IDs. If there are users with two different IDs, then they'll have to bite the bullet and accept the change of one ID. Unfortunately domain logins cannot have aliases.
• When you join Linux to AD using the realm command and an unprivileged account, you may encounter this 10 machine limit. Here's how to raise the limit.
• Do use ntpd to keep all the clients in time sync. Specify the domain servers as NTP servers in ntp.conf. I had an issue where one client wouldn't authenticate. All the config files were identical with a working client. Finally I realised I had not enabled and started ntpd. It turned out to be clock skew. Kerberos is sensitive to this.
• Do enable GSSAPI with MIC in sshd. It really works and you can use putty to ssh to the server without specifying a password provided the Windows user has authenticated to the domain.
• Do use AD security groups to restrict access to the Linux servers. Otherwise all AD users can login by default. This means that enrolling a new Linux user across all the servers is simply adding the user to your chosen security group. Create one if necessary. Oddjobd will take care of creating the home directory on first login, which is very nice. I used the simple access_provider. I couldn't get the ad access_provider and ad_access_filter to work, but this is probably because I couldn't work out the correct LDAP strings.
• You can also use a security group to specify who can have extra privileges in sudo.
• I used the deterministic hash scheme for mapping SIDs to UIDs because I didn't want to (and didn't have authority to) add attributes to the AD schema.
• When migrating existing user accounts, make sure you find all the places a user might have a file. Not just /home but also /var/spool/cron and /var/spool/mail. Kick all the users off and kill all of their processes before you do the chown. Since after the switchover the names will map to the new UIDs, you can cd /home and run a loop: for u in * do; chown -R $u $u; done. Also the cron and mail directories.
• If you have software that must have simple login IDs, i.e. fred and not fred@example.com, then you should set use_fully_qualified_names = False. This implies you cannot have a default_domain_suffix. If you have a single domain, then you don't need domain suffixes. If you have multiple domains, then this is beyond my knowledge. I found that some applications cannot handle usernames of the domain form. Even the crontab command will create and require cron files of the domain form if domain suffixes are enabled.
• I couldn't get the sssd idmap to work with Samba so I chose winbind. Also you have to use winbind if you have to support NTLM authentication.
• New: If you are running 32-bit applications, you should also install the 32-bit libsss* shared libraries corresponding to the 64-bit ones, otherwise those applications may not be able to get user account info via PAM. This showed up in icfb, an old 32-bit Cadence executable, that worked for local users (in /etc/passwd) but failed for SSSD authenticated users.
• New: If oddjob_mkhomedir doesn't work, as evidenced by no home directory created for a new login, check /var/log/messages. SELinux is probably blocking this. Either make the policy permissive, or create a policy for this.

DOS 6.22 printing to Samba fails with Path not found

My workplace wanted a NT server for DOS 6.22 clients replaced by a Samba server. No problem. Disk shares worked fine. But when it came to printing, this happened:

>net use lpt1 \\samba-server\printername
>copy con lpt1
Testing
^Z

Blah blah Path not found

I looked at the log file for the client in question and found these lines:

[2013/10/01 14:02:22.820899,3] smbd/vfs.c:905(check_reduced_name) check_reduced_name [DEV/LPT1] [/var/spool/samba]
[2013/10/01 14:02:22.820941,3] smbd/vfs.c:944(check_reduced_name) check_reduce_name: couldn't get realpath for DEV/LPT1 (NT_STATUS_OBJECT_PATH_NOT_FOUND)

Ah, was it trying to create a file called DEV/LPT1 in /var/spool/samba? But there is no subdirectory called DEV. So I did this:

# cd /var/spool/samba
# ln -s . DEV

Voila, printing worked from DOS. I can only surmise that DOS sends the whole path rather than just LPT1 to Samba or indeed any SMB server.

Hope this helps you if you need to convert any DOS clients to use Samba instead of NT.

Samba, SELinux and the homes share

As has been documented here and many other places, on Redhat, CentOS, Fedora and other distros that come with SELinux enabled, you have to enable the SELinux boolean samba_enable_home_dirs if you export the homes share. I did this but I still could not connect to the share. The usual error message is NT_STATUS_BAD_NETWORK_NAME.


It turns out that you need samba_export_all_ro or more likely, samba_export_all_rw enabled to mount the share. This was on CentOS 5.5. It could be that on this distro and version both come disabled by default.


Make sure though that SELinux is the cause. There are many other reasons for NT_STATUS_BAD_NETWORK_NAME. A quick way to check is to set SELinux to permissive temporarily to attempt the connection.

How to access CIFS shares from a user account on Ubuntu Lucid

A friend of mine has a Samba server which I set up for him. His problem was that although he could see the shares from the file browser using Connect to Server, they were not accessible from Thunderbird for attaching to emails, etc. and he had to do a copy to a local directory first.


I did a search and found tips involving setting up fstab. This was not satisfactory because the machine was a notebook and the server would not be accessible while on the road. Tips involving autofs and automount were also not satisfactory because of the complicated setup.


I figured that since the file browser could see the share, it must be mounted somewhere. The output of mount showed that it was mounted on $HOME/.gvfs. The problem is that theThunderbird file selector does not display dotfiles. Other programs may have a similar restriction. My solution was this:


ln -s .gvfs GVFS


I then instructed him to look for his share under GVFS. Actually Thunderbird can navigate to dotfiles, you have to click on the Type a file name icon at the top left and type in .gvfs, but I figured that this was much easier for the user.


If you make a bookmark in the file browser and also tell it to remember the credentials for the connection, it should be one-click to mount. I think this should work for the other types of mounts that the file browser can do, e.g. FTP.