Ok everyone, so I'm in middle of a pretty crazy project, but I'm making progress and I feel like I'm ALMOST there!
I'll give you a little background: I had a shared drive on a Windows 2003 server that filled up. The server was about to be phased out, so I decided rather than get a new hard drive, I'd move all the info from the Windows server to my sexy new SLES10 Linux server sitting next to it, with a terabyte of unused space.
All's well. I set up Samba, Winbind, nsswitch, all of those goodies, and I was able to connect to my Samba share on the Linux box via any Windows PC by using any active directory username/password housed on the Windows server (sweet, right?)
Ok, so that part's cool. Now I get to worry about security. I am at the point where I've mounted the shared drive on the linux side with the "acl" option, so I can use setfacl to add/remove permissions from the drives. So, for argument's sake, let's say my drive is called "company" - here's what I've done:
Code:
setfacl -R -m u::--- /company #Remove owner access from /company, recursively
setfacl -R -m g::--- /company #Remove all group access from /company, recursively
setfacl -R -m o::--- /company #Remove all world access from /company, recursively
Cool right? Now nobody has access to anything unless I specify it. Here's the fun part:
Code:
setfacl -R -m g:randomADgroup:rwx /company #Now everyone in randomADgroup (a group I've created and added a few people to in AD on the Windows server) has rwx access to /company and everything in it
I can fine tune my security in this way, but I don't want to do it via Unix. I want to do it via the Windows security dialogs (i.e. right click a folder, properties, security tab, check/uncheck the boxes, etc). According to this
http://www.adminkernel.com/linux/int...ry-using-samba and this
http://www.samba.org/samba/docs/man/...html#id2610746 I should be able to do it, as Samba provides mechanisms to map the Windows permissions settings into Unix ACLs as you set them on the Windows side.
When I try to change the settings via the Windows security dialog boxes, I get "access is denied." (i.e. if I try to add someone to a folder's access list in Windows, I can add them to the box but when I click apply it tells me access is denied). Now, I suspect that this is because in Unix,
I need to execute chmod commands as root, and when I connect to the Samba share from Windows I am connecting as "Administrator" or as another active directory user. I thought that I could get around this by creating a note in the smb.conf file to map the username "administrator" to "root" using a user map file. I created the file users.map in /etc/samba and then set the parameter username map = /etc/samba/users.map in smb.conf. According to this quote from the Samba documentation, that should work:
Quote:
username map (G)
This option allows you to specify a file containing a mapping of usernames from the clients to the server. This can be used for several purposes. The most common is to map usernames that users use on DOS or Windows machines to those that the UNIX box uses. The other is to map multiple users to a single username so that they can more easily share files.
Please note that for user or share mode security, the username map is applied prior to validating the user credentials. Domain member servers (domain or ads) apply the username map after the user has been successfully authenticated by the domain controller and require fully qualified enties in the map table (e.g. biddle = DOMAIN\foo).
The map file is parsed line by line. Each line should contain a single UNIX username on the left then a '=' followed by a list of usernames on the right. The list of usernames on the right may contain names of the form @group in which case they will match any UNIX username in that group. The special client name '*' is a wildcard and matches any name. Each line of the map file may be up to 1023 characters long.
The file is processed on each line by taking the supplied username and comparing it with each username on the right hand side of the '=' signs. If the supplied name matches any of the names on the right hand side then it is replaced with the name on the left. Processing then continues with the next line.
If any line begins with a '#' or a ';' then it is ignored.
If any line begins with an '!' then the processing will stop after that line if a mapping was done by the line. Otherwise mapping continues with every line being processed. Using '!' is most useful when you have a wildcard mapping line later in the file.
For example to map from the name admin or administrator to the UNIX name root you would use:
root = admin administrator
Or to map anyone in the UNIX group system to the UNIX name sys you would use:
sys = @system
You can have as many mappings as you like in a username map file.
If your system supports the NIS NETGROUP option then the netgroup database is checked before the /etc/group database for matching groups.
You can map Windows usernames that have spaces in them by using double quotes around the name. For example:
tridge = "Andrew Tridgell"
would map the windows username "Andrew Tridgell" to the unix username "tridge".
The following example would map mary and fred to the unix user sys, and map the rest to guest. Note the use of the '!' to tell Samba to stop processing if it gets a match on that line:
!sys = mary fred
guest = *
Note that the remapping is applied to all occurrences of usernames. Thus if you connect to \\server\fred and fred is remapped to mary then you will actually be connecting to \\server\mary and will need to supply a password suitable for mary not fred. The only exception to this is the username passed to the password server (if you have one). The password server will receive whatever username the client supplies without modification.
Also note that no reverse mapping is done. The main effect this has is with printing. Users who have been mapped may have trouble deleting print jobs as PrintManager under WfWg will think they don't own the print job.
Samba versions prior to 3.0.8 would only support reading the fully qualified username (e.g.: DOMAIN\user) from the username map when performing a kerberos login from a client. However, when looking up a map entry for a user authenticated by NTLM[SSP], only the login name would be used for matches. This resulted in inconsistent behavior sometimes even on the same server.
The following functionality is obeyed in version 3.0.8 and later:
When performing local authentication, the username map is applied to the login name before attempting to authenticate the connection.
When relying upon a external domain controller for validating authentication requests, smbd will apply the username map to the fully qualified username (i.e. DOMAIN\user) only after the user has been successfully authenticated.
An example of use is:
username map = /usr/local/samba/lib/users.map
Default: username map = # no username map
|
And by the way, my users.map file just has a single line:
Code:
root = Administrator
To me, this whole setup says that when I connect to the Samba share from my Windows server as "Administrator" I should be "tricking" unix into thinking I'm connecting as root, and I should be able to do anything root can do, like change file permissions. But...I can't.
Why?
See, it's such a simple question
Thanks!!!!!!
(and by the way, there are obviously much larger motivations for doing this than not wanting to buy a new hard drive. I am part of a rapidly expanding company and it would be so nice to use a single windows server to handle access to all shared drives. If I can make this work, I will hardly ever need to worry about integration of companies we may acquire whether they use windows, linux, even Mac OSX, because I will be able to handle all integration from my trusty windows server
)
