- 论坛徽章:
- 0
|
From SambaWiki
Contents [hide]
1 Which steps must be done to run Samba with AD-Integration
1.1 Prerequisites
1.2 Steps
1.3 Slightly Fuller Explenation
1.3.1 system-Config-authentication
1.3.2 Setting Up Kerberos
1.3.3 Setting up Samba
1.3.4 Adding this list to the password list.
1.3.5 Setting up PAM Authentication for Active Directory.
1.3.6 The Problem With Home Directories (overcome).
1.4 Authenticating share users and groups against active directory
[edit]Which steps must be done to run Samba with AD-Integration
[edit]Prerequisites
Software
Samba > 3.0.20
Kerberos MIT/Heimdal
ntp
often cups-Server
Permissions/Users
root-user on the server
an AD user with the permission to join AD ([Explanation]).
[edit]Steps
The time between DC's and the Samba server must be in sync
use ntp
configure your Kerberos environment kinit must be running fine
configure your smb.conf
security = ADS
join into the domain
kinit
net ads join
start the services
nmbd
smbd
winbindd
[edit]Slightly Fuller Explenation
Taken from http://ask.jara23.co.uk (by the Author)
To connect Linux(specifically RHEL) To Active Directory, you must have Kerberos (krb5), Winbind and Samba installed. Samba must be newer than 3.08, or it doesn't work. It will also be helpful during the testing to take the firewall down, to facilitate things working. A working firewall will be posted as soon as one has been worked out.. You will also need to configure PAM and nsswitch to get it authenticating against the Active Directory.
[edit]system-Config-authentication
On RHEL system, (or, presumably on Fedora core systems), you can use the system-config-authentication module. Simply chose winbind, and remember to chose "use kerberos". The Domain will be your windows Domain, and the Real will be your ADS real (eg WINDOWS.JARA23.CO.UK). You should then be able to click "join domain". This should connect you happily to the domain. Unfortunately, you won't see any errors until you exit the program. Normally, the biggest problem is with clock skew, ensure your clock time matches that of your ActiveDirectory server (for example by using ntpdate my.activedirectory.time.server.com). A fully populated and properly configured DNS system (including SRV records for your realm) for your LAN will save you many WTF! moments.
[edit]Setting Up Kerberos
The first thing to do is to set up the kerberos keys so that they work. Remember that kerberos is time-dependent, so you may have to make sure that the machine time is correct using a protocol like NTP.
Windows Servers should automatically update their clocks and Windows Workstations (2000 and later) synchronize their clocks to the Active Directory server. To emulate this behavior in Linux add the line server ad-server-name in your /etc/ntp.conf file and comment out all other server lines.
Below is a working krb5.conf file.
ALERT! Capitals are important here. Without capitalization of your realms and .domain_realm, kerberos won't be able to connect.
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = WINDOWS.JARA23.CO.UK
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
WINDOWS.JARA23.CO.UK = {
kdc = server.windows.jara23.co.uk
admin_server = server.windows.jara23.co.uk
default_domain = windows.jara23.co.uk
}
[domain_realm]
.kerberos.server = WINDOWS.JARA23.CO.UK
.windows.jara23.co.uk = WINDOWS.JARA23.CO.UK
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Save the file. Once the file is saved you can test it with this command: kinit admin@WINDOWS.JARA23.CO.UK. Remember, again, capitals are important. This should ask you for the password for the user account "admin", and then tell you if you have successfully logged in.
[edit]Setting up Samba
Samba is the software that allows you to connect Linux and UNIX clients to a Window's domain in the same way as you would a Windows 2000/XP machine. There are three important components, smbd, nmbd, and winbind, which all use the same configuration file: /etc/samba/smb.conf. Check the example configuration file below:
#GLOBAL PARAMETERS
[global]
workgroup = MIDGARD
realm = WINDOWS.JARA23.CO.UK
preferred master = no
server string = Linux Test Machine
security = ADS
encrypt passwords = yes
log level = 3
log file = /var/log/samba/%m
max log size = 50
printcap name = cups
printing = cups
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind nested groups = Yes
winbind separator = +
idmap uid = 600-20000
idmap gid = 600-20000
;template primary group = "Domain Users"
template shell = /bin/bash
[homes]
comment = Home Direcotries
valid users = %S
read only = No
browseable = No
[printers]
comment = All Printers
path = /var/spool/cups
browseable = no
printable = yes
guest ok = yes
A few important switches that might need a bit of explanation.
winbind use default domain = Yes removes the domain prefix from usernames, so you can login as Username instead of DOMAIN\Username or in some cases DOMAIN+Username (see next explanation).
winbind separateor = + : This is the seperator used to separate domain from username. Generally in documentation you will find this set to +. When you run testparm this will throw a warning, but that should be okay. It will mean that when you list the users you will see them in the form "MIDGARD+phb".
idmap uid = 600-2000 and idmap gid = 600-2000 set where the users from the AD will map onto the local system. ALERT! Whatever you do DO NOT set this to less than 600. and UNDER NO CIRUCMSTANCES set it lower than 100. This will lock you out of your root account.
template primary group = "Domain Users" sets the default group for users coming into the system. It makes sense for this to match the default group used by your Windows Machines. - Apparently no longer available!
template shell = /bin/bash gives the default shell to users logging onto your system. As this is not filled in by Active Directory, winbind does it all for you, locally.
winbind enum groups and winbind enum users allow the command "getent" to return with groups and users respectively. Without this, logons seem to fail.
Now, test the parameters file, and correct any syntax errors, using the command "testparm". It should print out that everything is okay, and a warning about the + sign possibly causing problems with domain joins. This can be safely ignored. The next thing is to start the services. All the documents on the web suggest starting them in order NMB, SMB, then Winbind. On Fedora Core 4 (and probably other Redhat-based systems), using the service smbd start and service windbindd start works fine. TIP note that there are two "d's" on winbindd.
Now to join your machine to the active directory. You will need the user-name and password to a Domain Administrator account to do this. The command you need to join the domain is net ads join -U sadwrn. This should then ask you for a password, and print a domain join notice.
To check that you have succesfully joined the domain, there are several things you can test.
net ads testjoin Test the connection to the Active Directory.
wbinfo -u Should now list all the members of the domain. TIP You might see a laod of machine names followed by $. eg myserver$. This is normall. You might want to try piping the output to more
wbinfo -g Should now list all the groups available in the domain. You might note that if you have more than one domain, that the members of the other domain will appear in the form "DOMAIN+mygroup". This is normal, and expected!
wbinfo -a username%password checks to see if username using password can connect to the domain. Remember the password, you have to type it as part of the command; it won't ask you for it later.
should wbinfo fail to return all groups or users in the active directory, simply increase the idmap gid upper boundary and restart winbind and SMB until all users and groups are produced in the list.
ALERT! NOTE: at this point you can lock your Active Directory Account!
[edit]Adding this list to the password list.
The next step is to get the passwd command to check the winbind list for usernames and groups. This is fairly straight forward as it only involves changing one file, /etc/nsswitch.conf and at that fairly minimally. Of course, backup this file before changing it.
passwd: files winbind
shadow: files winbind
group: files winbind
#hosts: db files nisplus nis dns
hosts: files dns wins
# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
ethers: db files
netmasks: files
networks: files dns
protocols: db files
rpc: files
services: files
netgroup: files
publickey: nisplus
automount: files
aliases: files nisplus
As you can see, the file is configured to check the local passwd file first. This is so that things like system and root accounts don't lag waiting for a response from the Active Directory, when won't be forthcomming. It also ensures that if there is a problem, Root and services will still function (for example, samba can't look up it's own account over Active Directory during startup!). Note that the following files (and symlinks) must be present in the system /lib directory:
libnss_winbind.so
libnss_winbind.so.2 -> libnss_winbind.so
libnss_wins.so
libnss_wins.so.2 -> libnss_wins.so
If you compiled from source you will probably have to copy these files manually after `make install` You should now be able to run getent passwd and see the local password list, and on the end of it, those that have been imported from the Active Directory. Now all that remains is setting up PAM authentication.
[edit]Setting up PAM Authentication for Active Directory.
ALERT! Before you start, backup you you /etc/pam.d directory. Failure at this stage can lock the entire machine. Log in a root account on a virtual terminal, and LEAVE IT LOGGED IN until such time as you have tested the new configuration. Perhaps log in TWO root accounts incase of mistakes.
On RedHat, changing the PAM configuration is as easy as changing one file, the /etc/pam.d/system-auth file. This file is responsible for directing the services that require authentication to the right mechanism to get a response. Change the file as follows:
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so
account required /lib/security/$ISA/pam_unix.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet
account sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
account required /lib/security/$ISA/pam_permit.so
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 type=
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_winbind.so use_first_pass
password required /lib/security/$ISA/pam_deny.so
session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session required /lib/security/$ISA/pam_winbind.so use_first_pass
Save the file, and change to another virtual terminal. Try logging in as a Member of the Active Directory. This should work, though you WILL see an error about missing home-directory (don't worry about that, we'll fix that later). If you have had a a previous user account on that machine that matches the log-in from the Active Directory, you will need to comment it out. (comment, not delete, that way you can restore if things go wrong). Check as many users as you can, until you feel comfortable that the mechanism works. ALERT! Remember to ensure that ROOT can still log in.
[edit]The Problem With Home Directories (overcome).
Once all the above is working, you might be tempted to reboot, and try to log in. Bad Idea. Currently no users have home-directories. This is a good thing, otherwise Linux would go away and fill your HD with a load of home directories for users that might never ever need to log on to your system. This means, however, that you will have to create them yourself. There is a bit of a Gotcha with this, however. By default the home directories are created under /home/DOMAIN/username. So, in our example, user phb's home directory will be found in /home/MIDGARD/shadowknight. You can specify the root of the home directory with the "template homedir = /home/%U" (or similar) option; this example is similar to *nix local user home directory structure and eliminates the (%D reference and) domain name from users' home directorys' paths. Since we're using the "winbind use default domain = yes" option, we're only planning to resolve the accounts for one domain anyway; there is no danger of account name overlap among trusted domains. Another Gotcha is that there is no group "ShadowKnight". So when you create the directory, as root, and then attempt to chown (shadowknight:shadowknight) it, it throws an error. What you need to do is to create the Directory MIDGARD, then create the directory shadowknight, then chown -R shadowknight:"Domain Users" shadowknight. This, of course, is a bit of a security problem. It leave the home directory open to anyone in "Domain Users" unless you remove permissions from that group. Implementation of Posix ACLs on the underlying file system partition also makes management and inheritance of complex ACLs much easier. With proper implementation of Posix ACLs (including default ACLs) and no security restrictions in smb.conf, Samba very closely approximates NT ACLs (including full configuration from within Windows Explorer Security tabs).
---ShadowKnight 06:37, 15 September 2006 (CDT)
If you'd ratehr have users home directories generated on the fly when they first login to your Linux machine, add this line of code in /etc/pam.d/sshd
session required /lib/security/pam_mkhomedir.so
--Nimbius 13:11, 31 October 2006 (CST)
[edit]Authenticating share users and groups against active directory
Yeah, this one took me about a day too.
[Pictures]
comment = Directory for storing pictures by jims users
path= /usr/local/pictures
Valid Users =@NETWORK+archival NETWORK+billybob NETWORK+jane
; public=no
writable=yes
browseable=yes
So what has this done? @NETWORK+archival gives any member of the archival group on NETWORK access to this share. NETWORK+billybob NETWORK+jane gives billybob and jane, both single user members of NETWORK, access to this share.
--Nimbius 13:11, 31 October 2006 (CST) |
|
免费注册
发表于 2006-12-11 16:13
