I know this question has probably been asked thousands of times, but I can't find any info on it anywhere:

I've read how to authenticate a Linux client against an Active Directory server, but is it possible to get the AD users' existing windows home directories to mount on the Linux client, or, better yet, be the home directory for the user on the Linux client?

I've been searching for anything related to automounting a windows share for a home folder, but all documents and questions lead to have locally create home folders on the Linux client, or a Linux server, which I don't want.

I know there could be a lot of permissions issues, but is this really impossible?

Could someone at least tell me to give up looking, or point me towards some documentation?

Thanks!

Bret

Surely, if you are authenticating the user against the AD DC and have configured the PAM modules correctly then /home/<username> will be that user's home directory on the AD FS?

I found that John H Terpstra's docs on Samba 3 to be the best guide to doing things like this - try using Google for "samba step by step" or "samba 3 by example"

So, it is possible?

I'll keep searching, and try your search recommendations.

Thanks.

Bret

Not only is it possible, I have had it working on a couple of occasions at places I have worked (though not, I might add, where I work now!)

Phil

I have to apologize, but I need to ask for more input, if you can give it:

I've read through most of Samba 3 Step by Step, and it seems as if 90% of it relates to having Samba servers and Windows clients.

Could you point me to a section that deals with Linux clients and Active Directory servers, or anything on using Windows AD users' home directories (from an AD Server) on Linux clients (assuming I can get winbind to allow the Linux client to authenticate to the AD server in the first place).

In other words, I don't want to have a Samba server at all. Just a Windows AD server, with the users' home directories on that AD server, and Linux clients that can be configured to authenticate to AD and automount their AD home directories.

Thanks again.

Bret

OK, you need to be concentrating on the PAM areas of the documentation - http://enterprise.linux.com/article....id=101&tid=100 gives you an idea of how to get the linux box/user to authenticate against the AD domain.

The previously mentioned docs will give you an idea about how to set the users home directory via SMB/AD authentication.

Some other useful links (ones I use for setting up this):

http://www.wlug.org.nz/ActiveDirectorySamba

http://us2.samba.org/samba/docs/man/...TO-Collection/

http://www.netadmintools.com/art172.html

http://www.samag.com/documents/s%3D9...414e/0414e.htm

http://www.pcquest.com/content/linux/2005/105010303.asp

http://acd.ucar.edu/%7Efredrick/linux/samba3/

Hope that helps, let me know if you need more guidance

Phil

Thanks very much.

I have a lot of reading to do!

Bret

If, by any chance, anyone checks this thread again:

I'm the original poster. With the helpful replies I got above, I have sucessfully connected a fedora core 4 box to a windows 2003 AD domain.

I can run wbinfo -u and -g to get a list of users and groups from the windows 2003 server, and I can run getent passwd, and it pulls user info from the 2003 server as well.

I can even get successfully authenticated to the 2003 server when I login at gdm.

The part I still can't get to work is the mounting of the network home directory on the 2003 server for the user. Maybe it's not possible, because I have not been able to find any mention of this in samba or winbind docs.

What I would like to have happen is to be able to login to the linux client as an AD user, and either have my home directory from \\win2003server.domain.com\Users\ mount as the user's home folder, or at least mount as another drive.

I have tried changing the template homedir to be \\win2003\Users\%U, \\win2003.domain.com\Users\%U, //win2003/Users/%U, and //win2003.domain.com/Users/%U.

These all show in the user home path when I do a getent password, but when I login, I get the error that the directory does not exist.

Obviously I'm doing something wrong. Is this even possible?

Thanks.

Bret

I think you need to be looking ar pam_mount - here is another link to how to do what you are after:

http://www.hants.lug.org.uk/cgi-bin/...ints/SambaAuth

That's exactly what I was looking for. Thanks!

I'll have to play around with it for a while before I'll know if I can get it to work, but if I do, I'll post my result here for others.

Thanks again!

Bret

Well, I've now run into another major difficulty.

I think I could get pam_mount to work, but mount.cifs apparently will not work with Windows 2003 to start with.

If I try to manually run a command like this:

# mount.cifs //domaincontroller/share/user_directory /home/DOMAIN/user_mount_point -o user=username

I either get:

# mount error 6 = No such device or address

which I have read may be caused by the fact that I am trying to mount a sub-directory of a share. I have tried mounting the share itself, and that gets the same error.

or I get:

# mount error 13 = Permission denied

no matter what credentials I give. I have read that this may be a bug in mount.cifs. By the way, mount.smbfs always fails with an SMB signing error, which is why I switched to mount.cifs.

In either case, I can't even determine what is the difference between commands that get me error #1 or error #2. And I can;t find any information on how to fix either.

Should I give up on this? It seems pretty impossible.

Bret

Just for anyone who comes across this thread having similar problems, I haven't completely figured it out, but I have solved a few problems:

The only way I can get mounting to work with Windows 2003 is to turn off SMB signing. This is a Group Policy in Windows 2003.

Also, it seems that you cannot mount a sub-directory under a share with Samba, so you have to mount the Users share, and use the --bind option of mount to re-mount a sub-directory of the mounted share to the individual user's home folder.

In other words, mount //server/Users to where ever you want on the linux client, then use --bind to mount /Users/username/ to /home/DOMAIN/username, or something similar. This seems to work because the permissions take care of any security issues this might have.

Still having problems with pam_mount, though, because we have a few sub-directories under /Users based on Group membership, such as /Users/Staff/Teachers, where I would have to have more than one variable in the volume command in pam_mount.

So, I'm still stuck, but a little closer to a solution.

Bret

Bret, thanks for all your comments, it has really helped me in trying to get FC4 to work with Server 2003 AD. My background is installed SFU3.5 on Server 2003 DCs and turned off SMB signing. Using Kerberos and pam_ldap.conf to do the authentication from FC4 to the AD. After looking at your comments I am now using pam_mount to automount the shares on the Windows Fileserver to the home directory of the user on Linux. One question, you said you got mount --bind to work, how? Where did you put the command?

In pam_mount.conf I have tried adding "--bind param1 param2" as an option to my volume mount, then "mount --bind param1 param2" on its own line and finally "mntagain param1 param2" on its own line but all with zero luck. My Windows share is for the Users folder and I don't want to have to make each individual user's folder a share.

Thanks.

Unfortunately, this is one of the big problems we still haven't figured out.

Basically, the only way we got this setup to work was by manually executing the mount commands. Since we still can't figure out how to handle multiple directory variables (i.e. when students login, the mount command would have to mount /Users/Students/Year/ and when teachers login they would get /Users/Staff/Teachers/, etc.), we haven't gotten far enough to figure out how to get the --bind part of the mount command to work automatically.

I assumed that you could stick the --bind portion of the command in pam_mount, but it sounds like you've tried every way that we would have, so it sounds like we've helped lead you to a dead-end as well! Sorry about that.

If you figure out how to get this to work, let me know, please!

Good luck.

Bret

I am trying to do the same. And I'm running into different problems.

What I've got

Server: Windows 2000 with Active Directory
FQDN: server.domain.local
Workstation: Ubuntu 5.10 (Breezy)

I've added the workstation to the Active Directory by following these steps:

Adding a Linux workstation to the Active Directory

Step 1:
Install the packages

Execute the following commands in a terminal (as root)
Code:

apt-get install krb5-user
apt-get install winbind samba

When installing Kerberos you have to configure your server (In my case the FQDN of the Domain controller

Step 2:
Edit /etc/krb5.conf

[logging]
default = FILE10000:/var/log/krb5lib.log

[libdefaults]
ticket_lifetime = 24000
default_realm = DOMAIN.LOCAL
default_tkt_enctypes = des3-hmac-sha1 dec-cbc-crc
default_tgs_enctypes = des3-hmac-sha1 dec-cbc-crc

[realms]
DOMAIN.LOCAL = {
kdc = server.domain.local
admin_server = server.domain.local
default_domain = DOMAIN.LOCAL
}

[domain_realm]
.domain.local = DOMAIN.LOCAL
domain.local = DOMAIN.LOCAL


Step 3:
Aanpassen van /etc/samba/smb.conf

Het volgende moet in je smb.conf staan
Code:

[global]
security = ads
netbios name = UBUNTU
realm = DOMAIN.LOCAL
password server = server.domain.local
workgroup = DOMAIN
idmap uid = 500 - 10000000
idmap uid = 500 - 10000000
winbind separator = +
winbind enum users = no
winbind enum groups = no
winbind use default domain = yes
template homedir = /home/%D/%U
template shell = /bin/bash
client use spnego = yes
domain master = no


Test settings with testparm from terminal

Step 4:
Edit /etc/nsswitch.conf

passwd: compat winbind
group: compat winbind
shadow: compat

hosts: files dns wins
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis


Step 5:
Modify PAM settings

/etc/pam.d/common-account
account sufficient pam_winbind.so
account required pam_unix.so


/etc/pam.d/common-auth
auth sufficient pam_winbind.so
auth required pam_unix.so nullok_secure use_first_pass


/etc/pam.d/common-password
password required pam_unix.so nullok obscure min=4 max=50 md5


/etc/pam.d/common-session
session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel


Step 6:
Create a directory that will hold the home directory's of the Domain users

In a terminal type

mkdir /home/DOMAIN


Stap 7:
Initialise Kerberos

Request a ticket(in terminal)
Code:

kinit administrator@DOMAIN.LOCAL

verify that you've recieved a ticket (in terminal)

klist


Step 8:
Add client to the Active Directory

net ads join -U administrator@DOMAIN.LOCAL


Step 9:
Reboot the workstation

You can now login with the useraccount from the Active Directory.


Now for the problem causing part.

Using the samba share on the server as home for the user (\\server\username = ~)

I just made a share on the Server for one user. Purely for testing purposes. I'm planning to use --bind in the future. But for now I just want to see it working. In both the share and NTFS permissions everybody has Full Controll (just testing for now)

How I did it

\\server\username mount as home (~)

(I havent gotten this to work perfectly, though the mounting works flawlesly)

Step 1:
Install packages

In a terminal (as root)
apt-get install libpam-mount
apt-get install smbfs


Step 2:
Modify pam_mount.conf

/etc/security/pam_mount.conf

debug 0 #I've got is set to 1 for testing
mkmountpoint 1
luserconf .pam_mount.conf

options_allow nosuid,nodev
options_deny suid,dev
options_require nosuid,nodev

lsof /usr/bin/lsof %(MNTPT)
fsck /sbin/fsck -p %(FSCKLOOP)

cifsmount /bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -S -o "user=%(USER)%(before=\",\" OPTIONS)"
smbmount /usr/bin/smbmount //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER)%(before=\",\" OPTIONS)"
smbumount /usr/bin/smbumount %(MNTPT)
umount /bin/umount %(MNTPT)
mntagain /bin/mount --bind %(PREVMNTPT) %(MNTPT)

volume * smb server & /home/GRAND/& uid=&,gid=&,dmask=0750,workgroup=DOMAIN - -


Stap 3:
Modify PAM

/etc/pam.d/common-auth
auth required pam_mount.so
auth sufficient pam_winbind.so use_first_pass
auth required pam_unix.so nullok_secure use_first_pass


/etc/pam.d/common-password
password sufficient pam_unix.so nullok obscure min=4 max=50 md5
password sufficient pam_winbind.so use_authtok
password required pam_deny.so


/etc/pam.d/common-session
session required pam_unix.so
session required pam_mkhomedir.so umask=0022 skel=/etc/skel
session optional pam_mount.so

Now when you log in the share is automaticaly mounted as ~. When not using GDM you'll be able to log in and access you home. Now we want to login using GDM. Now you'll get some new problems

Because you set the permissions with pam-mount the login process cannot lock certain files. For .ICEauthority and .Xauthority I've done the following.

Edit / Create a file called .bash_profile in the users home and add te following to it:

XAUTHORITY=/tmp/.Xauthority
export XAUTHORITY
ICEAUTHORITY=/tmp/.ICEauthority
export ICEAUTHORITY

And edit /etc/X11/gdm/gdm.conf and change the UserAuthDir
line so that it reads "UserAuthDir=/tmp"

Now these files are stored in /tmp where they can be locked.

And here I'm running into difficulties. There is also a .serverauth.xxxx (xxxx different every session) that has to be locked. And I can't find a way to have it stored in /tmp.

To see where the procces strands just login without GDM (in login screen press ctrl + alt + F1) and login as the domain user. then you can see the share is succesfully mounted. But you are unable to startx.

I've also tried it with KDE, but with the same results. To login with a gui, the proccess has to lock some files. This can't be done because you set you're file permissions in pam_mount.conf. Once these permissions are in place they cannot be changed. So it is not possible to lock a file in the users home directory.

So if anybody knows how you can bypass the locking of files in a users home, I'd really apreciate it if you would share this information.

Wes