Thursday, 26 June 2014

Connecting Linux machine to windows AD and mounting remote user dirs automagically ‒ how?

Dear lazy web,

I've been working for the last year as an informatics teacher at high school and I'm playing with the idea of trying to migrate a couple of machines (mine for the start, I still need to connect to remote win desktop for certain tasks :-D) fully to Linux which would work as well as the windows machines WRT network shares which are on a windows AD server that I don't have admin access to. There are couple of problems, some of which I was able to solve, some of which I have an idea how to solve and some of which I don't now at all how to solve, any pointers appreciated! I'm testing this on Fedora 20 by the way.

Joining the domain

This one took me a lot time to solve and I had a couple of times when I gave up. Mostly because I didn't know the AD server hostname and even when I found it, I still couldn't get it to work via the system-config-authentication, nor the config files in /etc. By chance I was lucky to run across a QA test case for joining the AD domain! Well, and that worked like a charm. So the trick is to run:

$ realm join --user=User ad.example.com

Logging in

Kinda superfluous for me, but a real need when there would be more users to use the computer. That was what I was originally trying to achieve. After joining the domain with the above example, it started to work magically. I don't remember if there was anything else that I needed to set up, probably not. But you definitely need oddjob-mkhomedir that sets up the environment when a new user (unknown to the local computer) logs in for the first time. I believe it should be installed automagically during the join. I've tried it in CLI and in LightDM, both worked by the time I successfully joined.

Mounting remote locations

Well, this is the last thing I was able to do. It does not require logging in, it does require joining the domain. You must fill your login credentials, though, if you don't have a guest share. I've run across a bug in gvfs-samba ‒ when I'm copying multiple files over the network, it hangs. So for the network shares I'm using Dolphin at the moment. The GUI managers I've tried work both in the same way, just go to the location bar, type smb://username@domain/share, you're asked for a password, then it mounts and you can use it. In Thunar, which uses gvfs, you need gvfs-samba package. You can also mount it in CLI:

gvfs-mount smb://username@domain/share

On my old notebook which was essentially multiple times upgraded old fedoras this also created a mount point in the filesystem (somewhere under /run/user/gvfs), in my new computer (which has fresh Fedora 20), this does not create a mount point in the filesystem. Quick search on the internet showed, I need gvfs-fuse package and its daemon running. Then it appears under /run/user/⟨uid⟩/gvfs/* which then can be easily symlinked for wine to appear as a drive if needed.

Mounting the shared network shares on login

Now, here's where I have vague idea that I could probably call something like gvfs-mount on login, the problem is that it needs password. Is there a way to pass the credentials from login credentials to the mount data? Or ask for them only for the first time and in gui (meaning the mount point is created automatically, the user is asked for login credentials which are then saved in his default keyring)? The path to network share should be same for all users.

Mounting user specific network shares on login

Now, the same as above, but the network path depends on the user, i.e. something like smb://username@domain/share/username.

Doing the above two for new users as well

How do I run a custom script when a local user is created during first remote login?

"Mounting" the network shares as drives in wine

Now, here I have an idea that some simple symlinking should do the trick, the network shares names should stay the same (even the directories they appear in the filesystem), so it shouldn't be a problem.

So, once again, any help, pointers, suggestions are very welcome, I'll try to keep this post updated with new information and new solutions.

UPDATE: Solution to user automount problem

So, with the help of people that commented in the comments section, I found a solution that's called pam_mount. I'm not sure how to do it the right way (TM), but here's what made it work for me:

  • Add auth optional pam_mount.so before auth sufficient pam_winbind.so cached use_first_pass, so that the credentials are shared between pam mount and login to AD. I added it to /etc/pam.d/system-auth, I'm not sure that's the correct way though.
  • Add session optional pam_mount.so so that pam_mount is executed at the start of the session. I added it to the end of the same file as above.
  • Edit /etc/security/pam_mount.conf.xml. Typical line would look like <volume user="*" sgrp="DOMAIN\domain users" fstype="cifs" server="domain.server.org" path="Shares/Usr_home/%(DOMAIN_USER)" mountpoint="/home/DOMAIN/%(DOMAIN_USER)/.ad/%(DOMAIN_USER)" />

And voila, it works. I only have one still unsolved issue with this, and that's I cannot get it not to use forceuid, forcegid and nounix mount options. I haven't tried yet, if it's a problem with pam_mount, or mount.cifs (i. e. if the server/client combination support cifs unix extensions like POSIX acls)...

7 comments:

LarryR said...

I have used mount.cifs(8) to mount shared Windows drives with the following syntax:

sudo mount \
-t cifs \
-o rw,credentials=CREDPATH,uid=UID,gid=GID \
//SRVIP/PATH MOUNTPOINT

where:

CREDPATH is a pathname to a credentials text file with permissions set to 600 containing your username, password, and domain name for the shared server;

UID and GID are the names or ID numbers for the user ownerships applied to the shared files, typically your own UID and GID;

SRVIP and PATH are the IP address of the server you're mounting and the path you'd like to use as the root when it's mounted;

MOUNTPOINT is the path name for a directory already existing that you'd like the shared drive mounted on.

You can sudo umount these shared mount points in the usual way when you're done. I built a simple script to mount and umount the most common I use.

Martin said...

Hi LarryR,

thanks for the reply. Yes, I'm aware of the mount.cifs command, but it's not what I need for several reasons:

* Needs either root access (or being in sudoers) or entry in fstab (both not manageable for multiple normal users with their own network share dirs).

* Needs credentials provided in plain text format, or as CLI input. Again, not manageable for multiple normal users with their own credentials.

LarryR said...

The sudo complaint is a reasonable complaint. The credentials requirement isn't necessarily so because the individual's file permissions should be 600. But, I'll be interested to find out what you end up with.

Martin said...

Even 600 permissions leaves the credentials in plain text, I'd prefer them to be either in keyring or taken directly from login (as they are precisely the same), not sure if that's possible in linux, though.

Anonymous said...

This might help http://blog.cyphermox.net/2008/10/automatic-mounting-of-samba-shares.html?m=1

Anonymous said...

pam_mount and mount -t cifs //example.org/testshare /mnt/ -o sec=krb5

Anonymous said...

You might try autofs too. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-ldap-autofs.html

There was also an sssd module that remapped windows UIDs to unix UIDs in F20.

I would probably try the pam route first and would actually auth the users via pam. Also use like ignore root, or optional and such, so your root or management accounts don't get hung up because the AD server went down.

This thread might help, especially the first 2 links referenced.
http://nixcraft.com/showthread.php/17146-AutoFS-with-CIFS-HOWTO