TechTutorials - Free Computer Tutorials  







Integrating a Linux server into Active Directory using Samba Hot
 


Added: 07/24/2008, Hits: 22,742, Rating: 0, Comments: 0, Votes: 0
Add To Favorites | Comment on this article
It's fairly well known that Samba can be used to allow access to Windows file shares from a Linux server or to create shares on Linux servers that are accessible to Windows clients through Explorer. One of the big challenges with implementing Samba is typically user access. In most cases, a user needs separate Windows and Linux user accounts to provide single sign on access for a Windows PC accessing a Samba shared directory. At best, a Linux server could be configured to forward logon requests to a specific Windows server. Duplicate user accounts still had to exist on the Linux server however, keeping passwords synchronized was not necessary.

What is not as well known is that recent versions of Samba allow a Linux server to join a Windows Domain as a member server and use the existing Active Directory infrastructure to process all authentication requests.

This has two primary benefits:

  1. Users and administrators no longer have to deal with separate Unix accounts for accessing file shares on Linux servers.

  2. The Linux server can successfully pass logon requests to any available domain controller rather than being tied to a single NT4-stye PDC.


This guide will demonstrate how to join your Linux server to a Windows 2000/2003 Active Directory domain and some general guidelines for controlling file access using access control lists.

Prerequisites:
My implementation is done using RedHat Enterprise ES 3.0 although nothing in this guide is particularly specific to that distribution other than it has ACL support compiled into the kernel by default. Many other distributions will have this also. If not, you’ll need to compile a new kernel with Access List Support enabled for the particular filesystem you are using.

You will also need the following RPMs installed. Any newer versions should work as well.

  • samba-3.0.9-1.3E.3

  • samba-common-3.0.9-1.3E.3

  • samba-client-3.0.9-1.3E.3

  • krb5-workstation-1.2.7.52

  • krb5-libs-1.2.7-52

  • krb5-devel-1.2.7-52


In addition, any filesystems that will contain Samba shared folders must also be mounted with access list support. Configure this in /etc/fstab:

Code :

# device name mount point fs-type options dump-freq pass-num

/dev/sdb3 /home ext3 defaults,acl 1 2



Then remount the share for the change to be applied:

Code :

umount /home
mount /home


Kerberos config:
Samba uses Kerberos to securely transmit authentication requests to a Windows DC. This is a working example of a Kerberos config file. Lines that are changed from the defaults are highlighted. Be sure to use the exact same case as in the example.

/etc/krb5.conf

Code :

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
ticket_lifetime = 24000
default_realm = DOMAIN.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false

[realms]
DOMAIN.LOCAL = {
kdc = Specify the IP of any DC
default_domain = domain.local
}

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

[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf

[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}


Winbind config:
Winbind is a service that allows Windows user and group accounts to by dynamically mapped to a predefined pool of Linux user and group IDs. This service is what eliminates the need to maintain redundant user accounts. Make the following changes to /etc/nsswitch:

Code :

passwd: files winbind
shadow: files
group: files winbind


It’s also a good idea to set winbind to start up automatically if the server is rebooted:

Code :

chkconfig --level 2345 winbind on


Samba config:
The bulk of the customization is done in the main Samba configuration file. On most distributions this is /etc/samba/smb.conf.

The following config settings should be specified in the [global] section. Note that this is not a complete smb.conf file. These settings should be merged into your existing config file.

Code :

# This is the domain name that appears on PCs when logging in
workgroup = SHORT-DOMAIN-NAME

# This should be the server hostname
netbios name = servername

# This should match the Kerberos realm specified in krb5.conf
realm = DOMAIN.LOCAL

# Specify a description that will display in My Network Places
server string = Description

# Using a star will cause Samba to search for any available DC to handle login requests
password server = *

# Set these options if your DCs are Windows 2003
client use spnego = no
server signing = auto

# These options allow Windows clients to modify permissions on Samba shared files and folder through the Security interface in Explorer.
nt acl support = yes
map acl inherit = yes

# This tells Samba to use Active Directory for security
security = ADS
encrypt passwords = yes

# This defines the UID and GID pool that Winbind will use. These numbers should not already be assigned to existing Linux users or groups.
idmap uid = 15000-20000
idmap gid = 15000-20000
winbind use default domain = yes


The following is an example of a share declaration. The only thing to note about this are the last two ‘inherit’ statements. These state that any new objects created in the share will inherit both the ACL permissions and Unix permissions of its parent object. There’s a pretty significant reason for doing this that I’ll elaborate on later.

Code :

[test]
comment = Testing AD Integration
browseable = yes
writeable = yes
path = /home/test
inherit acls = yes
inherit permissions = yes



When finished, make sure to run the testparm command to proof your config file for errors.

Join to domain:

Samba and winbind should both be shut down before joining to the domain

Code :

service smb stop
service winbind stop


This command will attempt to create a computer account in the domain. The username specified should be a Windows user account that has the ability to join machines to the domain.

Code :

net ads join –U Administrator


Enter the password when prompted. You should get a message:

Code :

Joined 'SERVER' to realm 'DOMAIN.NAME’


If you look in Active Directory Users and Computers, you should see a new account in the Computers container for the Linux server.

You can create the computer account in a particular OU like this:

Code :

net ads join “List/OU/Hierarchy/Here” –U Administrator


Start Samba and Winbind back up:

Code :

service smb start
service winbind start


At this point we should be able to query Active Directory. The following commands should display lists of AD user and group accounts.

Code :

wbinfo –u

wbinfo –g



Correct use of ACLs:

By now we should have a Linux server that is capable of understanding Windows users and groups. We also have a shared folder. The final step is assigning permissions to the share to allow access.

The most efficient process I’ve found for controlling access involves three things:

  1. Assigning Unix permissions
  2. Assigning Explicit ACL permissions
  3. Assigning Default ACL permissions

When assigning Unix permissions we will restrict them to effectively push all access control decisions to the ACL:

Code :

chmod 770 /home/test
chown root:root /home/test


When calculating effective shared permissions in Windows, you are granted the more restrictive of the share permissions or the NTFS permissions. It’s a common practice to reduce complexity by giving everyone Full Control share permissions and using just the NTFS permissions for access control.

When sharing a folder from a Linux server, a user’s effective permissions are the combination of Unix permissions and ACL permissions. By setting our Unix permission this way, we are reducing complexity by using just the ACL permissions for access. If a user or group does not match an ACL entry, all access is denied. This strategy still allows us the ability to assign useful Unix permissions for users accessing these files in other methods (FTP, telnet logon, etc.) The key is that the Other group has no access at all.

Explicit ACL permissions are used to grant access to a specific object:

Code :

setfacl –m g:”DOMAIN\group-name”:rwx /home/test


This creates an access list entry giving full control to the members of the specified Active Directory group. The level of access can be set to read only by changing the rwx to r-x. ACL entries can also be made for individual users.

This ACL entry causes the Unix group-owner of the directory to have no access.

Code :

setfacl –m g::--- /home/test


If the group-owner remains ‘root’ then this is unnecessary, however if any Windows user ever modifies the properties of the directory (attempts to change permissions through the Windows Security dialog box, for example) the group-owner will become the POSIX compliant primary group of the user that made the change. In a domain environment, this group is almost always the Domain Users group. This setting prevents inadvertently giving full access of the share to the Domain Users group.

Default ACL permissions are permissions that will be inherited by objects created within the directory:

Code :

setfacl –d –m g:”DOMAIN\group-name”:rwx /home/test
setfacl –d –m g::--- /home/test


We set these the same as the explicit permissions since we want all files created in the share to inherit the same access as the share itself. The only difference is the –d flag in the command.

Setting our permissions this way used in conjunction with the ‘inherit’ statements in the smb.conf file allow us to effectively mimic the way Windows handles permissions on shared files.

Our final share permissions should look like this:


Code :

#ls –al directory

drwxrwx---+ 4 root root 4096 Nov 27 14:14 test

#getfacl directory

# file: test
# owner: root
# group: root
user::rwx
group::---
group:Administrators:rwx
mask::rwx
other::---
default:user::rwx
default:group::---
default:group:Administrators:rwx
default:mask::rwx
default:other::---


Access List command reference:

getfacl filename - Display ACL for file/folder
setfacl -m [u|g]:"DOMAIN\account":rwx directory - Sets ACL entry for a user or group
setfacl -x [u|g]:"DOMAIN\account” directory - Removes specified ACL entry
setfacl -m [u|g]:"DOMAIN\account":--- directory - Sets a no access ACL (Explicit deny)
setfacl -d -m [u|g]:"DOMAIN\account":rwx directory -Sets Default ACL (works on folders only)





Comments (0)

Be the first to comment on this article


Related Items








7 Seconds Resources, Inc.




IT Showcase