cowanrl
09-28-2003, 04:51 PM
This is the first line in the Samba 3.0 release notes:
Active Directory support. Samba 3.0 is now able to
join a ADS realm as a member server and authenticate
users using LDAP/Kerberos.
This is something Samba couldn't do before and since I'm using a Win2k AD domain on my home network, I decided to see if I could get it to work.
Probably the only advantage to this is if you are running a Win2k AD domain in native mode. In that case, Samba was not previously able to join the domain.
If you are running the Win2k AD domain in mixed mode, Samba could join the domain as if it were an NT 4 type of domain. However, it used the NT4 type of authentication, not Kerberos.
If you're not familiar with the different AD modes, here's a breif explanation. In mixed mode, all windows clients are able to authenticate to the domain including Win9x, NT4, Win2k and XP Pro. Samba could also be a member of this domain. In native mode, only Win2k and XP Pro clients can belong to the domain. If you have a network with just Win2k and XP Pro clients, native mode is the way to go.
The only version of Linux I"ve tried this on is Red Hat 9 so that's what this is geared towards. It should work on any version of Linux though once you get Kerberos installed and working.
The most crucial thing you need to make this work is to have Kerberos V5 installed on your Red Hat machine. The 2 rpm packages you need to have installed are krb5-libs and krb5-workstation. You should also install the krb5-server package so the documentation pages that are installed with this package are available. You will not need to configure your RH 9 machine as a Kerberos server though.
I already had them installed on my machine but you should be able to find them on the RH 9 CDs(I'm not sure which one). You can check to see if they are already installed by using the rpm -q command:
rpm -q krb5-libs
rpm -q krb5-workstation
rpm -q krb5-server
should return the version numbers, not error messages.
Once you find them on your CDs, you can install them with the GUI package manager or from the command line using:
rpm -ivh <packagename>
Once you get Kerberos installed on your Red Hat machine, there's a few critical things you need to check:
1. The time on your Win2k AD server and your Red Hat machine must match. The default Kerberos setting allows for a 5 minute discrepency. I reccomend setting them as close as possible to allow for drift over time. This is ABSOLUTELY CRITICAL!!. If the clocks don't match, it won't work.
This also applies to any other machine in your AD domain you want to authenticate to from your RH 9 machine using Kerberos.
2. Any user account in the Win2k AD domain you are going to use for authentication using Kerberos must have had the password changed at least once since it was created. If the password has never been changed since the account was created THIS WON'T WORK!!. On the accounts I used, I just changed the passwords, then changed them right back to their originals.
This is something that tripped me up until I found a small note about it in one of the HOWTOs. I had to change the password on both the administrator account and the user account I normally use so this would work.
This was the setup on my network:
Linux:
Red Hat 9 with Samba 2.2.8a installed from the RPM package from Samba.org, not from the RH CDs.
host/NetBIOS name - delldim
Samba server was set up using security = server and used the Win2k server for authentication.
Win2k
Win2k AD DC running SP4
Machine name - pe500sc
Second Win2k AD DC named mainnt
AD domain name - the_cowans.com
Network domain name - the_cowans.com
Running DNS for the entire network
Running WINS for the entire network
Here's the steps I followed to get Samba 3.0 to join the AD domain using Kerberos:
1. I removed the old version of Samba from the computer with this command:
rpm -e samba
If you installed Samba from the RH CDs, you will probably have to remove more than one rpm package. You can use the RH 9 GUI package manager or execute:
rpm -qa | grep samba
to list the samba packages that are installed, then uninstall them from the command line.
You should uninstall your current version of Samba before installing Samba 3. When you remove Samba, the rpm command will back up your smb.conf file to smb.conf.rpmsave. I reccomend you make a back up copy of it yourself though.
2.Download and install Samba 3 rpm package for RH9.
Once it's downloaded, just use:
rpm -ivh samba-3.0.0-1.i386.rpm
Once you install it, make the smb.conf.rpmsave file your active smb.conf file and start Samba. It should work as it did before.
Once you've tested Samba 3 to be sure it's working properly, it's important that you stop it before you continue with further configuration. Execute as root:
service smb stop
3. Configure Kerberos.
If you're not familiar with Kerberos, there's a few things you can read to familiarize yourself with it:
The Red Hat 9 Linux Reference Guide, Chapter 17, Kerberos(part of the RH9 documentation set.
The files:
/usr/share/doc/krb5-workstation-1.2.7/user-guide.html
/usr/share/doc/krb5-server-1.2.7/admin.htm. and install.html
The important thing here is the /etc/krb5.conf file. There should be an example one in /etc you can modify(that's what I did). Here's a copy of mine:
[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 = THE_COWANS.COM
[realms]
THE_COWANS.COM = {
kdc = pe500sc.the_cowans.com
kdc = mainnt.the_cowans.com
admin_server = pe500sc.the_cowans.com
default_domain = the_cowans.com
}
[domain_realm]
.the_cowans.com = THE_COWANS.COM
the_cowans.com = THE_COWANS.COM
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
All of the literature I read said the realm name should be in upper case but doesn't have to be. I took their recommendation.
As you see, I named my realm the same as the AD Domain name. It just so happens that my AD Domain name is the same as my network domain name but that's not always the case.
Once you get your krb5.conf file done, you can test it with the kinit command. Execute:
kinit username@REALM
username is the name of an account in your AD Domain. It should prompt you for a password. Enter the password for that user in the AD Domain.
If it executes without error, the execute klist to see your Kerberos ticket.
Here's the commands I entered:
[rlcowan@delldim rlcowan]$ kinit rlcowan@THE_COWANS.COM
Password for rlcowan@THE_COWANS.COM:
[rlcowan@delldim rlcowan]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rlcowan@THE_COWANS.COM
Valid starting Expires Service principal
09/28/03 15:35:40 09/29/03 01:35:40 krbtgt/THE_COWANS.COM@THE_COWANS.COM
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rlcowan@delldim rlcowan]$
If you get any error messages, make sure that:
- you have no spelling errors in your krb5.conf file
- the times are synched on your machines
- the password has been changed at least once on the username you are using.
Once you get a ticket from the AD DC, test it out by using Kerberos authentication with the smbclient command to view the shares on your Win2k AD DC:
smbclient -L /servername -k
That should return a list of all the shares on the DC.
Here's how the command worked on my machine:
[rlcowan@delldim rlcowan]$ smbclient -L /pe500sc -k
Sharename Type Comment
--------- ---- -------
photos Disk
IPC$ IPC Remote IPC
D$ Disk Default share
rlcowan Disk
Savefile Disk
NETLOGON Disk Logon server share
Family Disk
ADMIN$ Disk Remote Admin
SYSVOL Disk Logon server share
Linux Disk
C$ Disk Default share
Server Comment
--------- -------
Workgroup Master
--------- -------
[rlcowan@delldim rlcowan]$
After you execute that, you should have another ticket for the server. You can view it with klist likethis:
[rlcowan@delldim rlcowan]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rlcowan@THE_COWANS.COM
Valid starting Expires Service principal
09/28/03 15:35:40 09/29/03 01:35:40 krbtgt/THE_COWANS.COM@THE_COWANS.COM
09/28/03 15:42:13 09/29/03 01:35:40 pe500sc$@THE_COWANS.COM
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rlcowan@delldim rlcowan]$
4. Configure Samba
When you install Samba from the Samba.org rpm package, it will also install SWAT. Before you configure Samba, I suggest you fire up SWAT and read the document listed on the SWAT home page titled "The Samba HOWTO Collection" It has a section in it that deals with Win2k AD and Kerberos.
You now need to make the changes to your smb.conf file to enable Kerberos authentication and so you can join the AD domain. The important lines in smb.conf are:
realm = YOUR.REALM
security = ads
password server = <ip address or name of DC>
Here's a copy of my smb.conf file:
[global]
workgroup = the_cowans
netbios name = delldim
server string = Dell Dimension 8200
security = ads
realm = THE_COWANS.COM
password server = 10.10.1.35
encrypt passwords = yes
printcap name = /etc/printcap
load printers = yes
printing = cups
log file = /var/log/samba/%m.log
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = no
domain master = no
preferred master = no
wins server = 10.10.1.3
dns proxy = no
#============================ Share Definitions ==============================
[savefile]
path = /savefile
browseable = yes
writeable = yes
guest ok = no
[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
create mode = 0664
directory mode = 0775
[printers]
comment = All Printers
path = /var/spool/samba
browseable = yes
guest ok = yes
writable = no
printable = yes
Once you make the changes to smb.conf, you need to join the AD domain. Before you do so there are 2 things you should chedk:
- if there is a file named /etc/samba/secrets.tdb either move it or rename it. This file would be from your previous connections to the domain. A new one will be created when you join the domain.
- if there is an existing machine account in your AD domain for your Samba server, delete it. A new one will be created when you join the AD domain.
Here's the commands I used as root to join the AD domain:
kinit administrator@THE_COWANS.COM
net ads join -Uadministrator%password
You need to use the username of any account in your AD domain that has authority to join computers to the domdain. The kinit command gets the Kerberos ticket you need. The second command joins the domain.
If you're familiar with the command used with Samba 2.2 to join a domain, you'll notice the difference. smbpasswd is not used any more for this purpose.
If you successfully join the AD domain, you should receive a message something like Successfully joined the Domain. I'm not sure of the exact message. You should also see a new /etc/samba/secrets.tdb file. There should also be a new machine account creted in your Active Directory. If you look at the properties of the machine account, you should see that the OS is listed as Samba 3.0.
Once you've successfully joined the AD domain, start Samba using:
service smb start
5. Test
You should now be able to access the shares on your Samba server from your Windows machines. In my case, I have XP Pro machines as clients. I can access the shares on my Red Hat 9, Samba 3 server withouth any problems.
One thing about using this type of authentication is that you don't need to create Samba accounts on the Linux server with the smbpasswd command. There is no need for the /etc/samba/smbpasswd file.
However, each user that accesses the Samba server will still need to have a vilid Linux account on the server that matches the account in the AD domain. The password for that account does not need to match the Win2k AD domain account password. The account doesn't even need to have the ability to log in locally to the Linux machine. It does have to exist however and it must have the proper permissions to the directories you are sharing out with Samba for the user to access them. This hasn't changed from Samba 2.2
To get around the need for for local Linux accounts, you need to use winbindd. It'll be interesting to see how that will work in conjuction with an AD domain. But that's another subject.
Active Directory support. Samba 3.0 is now able to
join a ADS realm as a member server and authenticate
users using LDAP/Kerberos.
This is something Samba couldn't do before and since I'm using a Win2k AD domain on my home network, I decided to see if I could get it to work.
Probably the only advantage to this is if you are running a Win2k AD domain in native mode. In that case, Samba was not previously able to join the domain.
If you are running the Win2k AD domain in mixed mode, Samba could join the domain as if it were an NT 4 type of domain. However, it used the NT4 type of authentication, not Kerberos.
If you're not familiar with the different AD modes, here's a breif explanation. In mixed mode, all windows clients are able to authenticate to the domain including Win9x, NT4, Win2k and XP Pro. Samba could also be a member of this domain. In native mode, only Win2k and XP Pro clients can belong to the domain. If you have a network with just Win2k and XP Pro clients, native mode is the way to go.
The only version of Linux I"ve tried this on is Red Hat 9 so that's what this is geared towards. It should work on any version of Linux though once you get Kerberos installed and working.
The most crucial thing you need to make this work is to have Kerberos V5 installed on your Red Hat machine. The 2 rpm packages you need to have installed are krb5-libs and krb5-workstation. You should also install the krb5-server package so the documentation pages that are installed with this package are available. You will not need to configure your RH 9 machine as a Kerberos server though.
I already had them installed on my machine but you should be able to find them on the RH 9 CDs(I'm not sure which one). You can check to see if they are already installed by using the rpm -q command:
rpm -q krb5-libs
rpm -q krb5-workstation
rpm -q krb5-server
should return the version numbers, not error messages.
Once you find them on your CDs, you can install them with the GUI package manager or from the command line using:
rpm -ivh <packagename>
Once you get Kerberos installed on your Red Hat machine, there's a few critical things you need to check:
1. The time on your Win2k AD server and your Red Hat machine must match. The default Kerberos setting allows for a 5 minute discrepency. I reccomend setting them as close as possible to allow for drift over time. This is ABSOLUTELY CRITICAL!!. If the clocks don't match, it won't work.
This also applies to any other machine in your AD domain you want to authenticate to from your RH 9 machine using Kerberos.
2. Any user account in the Win2k AD domain you are going to use for authentication using Kerberos must have had the password changed at least once since it was created. If the password has never been changed since the account was created THIS WON'T WORK!!. On the accounts I used, I just changed the passwords, then changed them right back to their originals.
This is something that tripped me up until I found a small note about it in one of the HOWTOs. I had to change the password on both the administrator account and the user account I normally use so this would work.
This was the setup on my network:
Linux:
Red Hat 9 with Samba 2.2.8a installed from the RPM package from Samba.org, not from the RH CDs.
host/NetBIOS name - delldim
Samba server was set up using security = server and used the Win2k server for authentication.
Win2k
Win2k AD DC running SP4
Machine name - pe500sc
Second Win2k AD DC named mainnt
AD domain name - the_cowans.com
Network domain name - the_cowans.com
Running DNS for the entire network
Running WINS for the entire network
Here's the steps I followed to get Samba 3.0 to join the AD domain using Kerberos:
1. I removed the old version of Samba from the computer with this command:
rpm -e samba
If you installed Samba from the RH CDs, you will probably have to remove more than one rpm package. You can use the RH 9 GUI package manager or execute:
rpm -qa | grep samba
to list the samba packages that are installed, then uninstall them from the command line.
You should uninstall your current version of Samba before installing Samba 3. When you remove Samba, the rpm command will back up your smb.conf file to smb.conf.rpmsave. I reccomend you make a back up copy of it yourself though.
2.Download and install Samba 3 rpm package for RH9.
Once it's downloaded, just use:
rpm -ivh samba-3.0.0-1.i386.rpm
Once you install it, make the smb.conf.rpmsave file your active smb.conf file and start Samba. It should work as it did before.
Once you've tested Samba 3 to be sure it's working properly, it's important that you stop it before you continue with further configuration. Execute as root:
service smb stop
3. Configure Kerberos.
If you're not familiar with Kerberos, there's a few things you can read to familiarize yourself with it:
The Red Hat 9 Linux Reference Guide, Chapter 17, Kerberos(part of the RH9 documentation set.
The files:
/usr/share/doc/krb5-workstation-1.2.7/user-guide.html
/usr/share/doc/krb5-server-1.2.7/admin.htm. and install.html
The important thing here is the /etc/krb5.conf file. There should be an example one in /etc you can modify(that's what I did). Here's a copy of mine:
[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 = THE_COWANS.COM
[realms]
THE_COWANS.COM = {
kdc = pe500sc.the_cowans.com
kdc = mainnt.the_cowans.com
admin_server = pe500sc.the_cowans.com
default_domain = the_cowans.com
}
[domain_realm]
.the_cowans.com = THE_COWANS.COM
the_cowans.com = THE_COWANS.COM
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
All of the literature I read said the realm name should be in upper case but doesn't have to be. I took their recommendation.
As you see, I named my realm the same as the AD Domain name. It just so happens that my AD Domain name is the same as my network domain name but that's not always the case.
Once you get your krb5.conf file done, you can test it with the kinit command. Execute:
kinit username@REALM
username is the name of an account in your AD Domain. It should prompt you for a password. Enter the password for that user in the AD Domain.
If it executes without error, the execute klist to see your Kerberos ticket.
Here's the commands I entered:
[rlcowan@delldim rlcowan]$ kinit rlcowan@THE_COWANS.COM
Password for rlcowan@THE_COWANS.COM:
[rlcowan@delldim rlcowan]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rlcowan@THE_COWANS.COM
Valid starting Expires Service principal
09/28/03 15:35:40 09/29/03 01:35:40 krbtgt/THE_COWANS.COM@THE_COWANS.COM
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rlcowan@delldim rlcowan]$
If you get any error messages, make sure that:
- you have no spelling errors in your krb5.conf file
- the times are synched on your machines
- the password has been changed at least once on the username you are using.
Once you get a ticket from the AD DC, test it out by using Kerberos authentication with the smbclient command to view the shares on your Win2k AD DC:
smbclient -L /servername -k
That should return a list of all the shares on the DC.
Here's how the command worked on my machine:
[rlcowan@delldim rlcowan]$ smbclient -L /pe500sc -k
Sharename Type Comment
--------- ---- -------
photos Disk
IPC$ IPC Remote IPC
D$ Disk Default share
rlcowan Disk
Savefile Disk
NETLOGON Disk Logon server share
Family Disk
ADMIN$ Disk Remote Admin
SYSVOL Disk Logon server share
Linux Disk
C$ Disk Default share
Server Comment
--------- -------
Workgroup Master
--------- -------
[rlcowan@delldim rlcowan]$
After you execute that, you should have another ticket for the server. You can view it with klist likethis:
[rlcowan@delldim rlcowan]$ klist
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: rlcowan@THE_COWANS.COM
Valid starting Expires Service principal
09/28/03 15:35:40 09/29/03 01:35:40 krbtgt/THE_COWANS.COM@THE_COWANS.COM
09/28/03 15:42:13 09/29/03 01:35:40 pe500sc$@THE_COWANS.COM
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
[rlcowan@delldim rlcowan]$
4. Configure Samba
When you install Samba from the Samba.org rpm package, it will also install SWAT. Before you configure Samba, I suggest you fire up SWAT and read the document listed on the SWAT home page titled "The Samba HOWTO Collection" It has a section in it that deals with Win2k AD and Kerberos.
You now need to make the changes to your smb.conf file to enable Kerberos authentication and so you can join the AD domain. The important lines in smb.conf are:
realm = YOUR.REALM
security = ads
password server = <ip address or name of DC>
Here's a copy of my smb.conf file:
[global]
workgroup = the_cowans
netbios name = delldim
server string = Dell Dimension 8200
security = ads
realm = THE_COWANS.COM
password server = 10.10.1.35
encrypt passwords = yes
printcap name = /etc/printcap
load printers = yes
printing = cups
log file = /var/log/samba/%m.log
max log size = 0
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
local master = no
domain master = no
preferred master = no
wins server = 10.10.1.3
dns proxy = no
#============================ Share Definitions ==============================
[savefile]
path = /savefile
browseable = yes
writeable = yes
guest ok = no
[homes]
comment = Home Directories
browseable = no
writable = yes
valid users = %S
create mode = 0664
directory mode = 0775
[printers]
comment = All Printers
path = /var/spool/samba
browseable = yes
guest ok = yes
writable = no
printable = yes
Once you make the changes to smb.conf, you need to join the AD domain. Before you do so there are 2 things you should chedk:
- if there is a file named /etc/samba/secrets.tdb either move it or rename it. This file would be from your previous connections to the domain. A new one will be created when you join the domain.
- if there is an existing machine account in your AD domain for your Samba server, delete it. A new one will be created when you join the AD domain.
Here's the commands I used as root to join the AD domain:
kinit administrator@THE_COWANS.COM
net ads join -Uadministrator%password
You need to use the username of any account in your AD domain that has authority to join computers to the domdain. The kinit command gets the Kerberos ticket you need. The second command joins the domain.
If you're familiar with the command used with Samba 2.2 to join a domain, you'll notice the difference. smbpasswd is not used any more for this purpose.
If you successfully join the AD domain, you should receive a message something like Successfully joined the Domain. I'm not sure of the exact message. You should also see a new /etc/samba/secrets.tdb file. There should also be a new machine account creted in your Active Directory. If you look at the properties of the machine account, you should see that the OS is listed as Samba 3.0.
Once you've successfully joined the AD domain, start Samba using:
service smb start
5. Test
You should now be able to access the shares on your Samba server from your Windows machines. In my case, I have XP Pro machines as clients. I can access the shares on my Red Hat 9, Samba 3 server withouth any problems.
One thing about using this type of authentication is that you don't need to create Samba accounts on the Linux server with the smbpasswd command. There is no need for the /etc/samba/smbpasswd file.
However, each user that accesses the Samba server will still need to have a vilid Linux account on the server that matches the account in the AD domain. The password for that account does not need to match the Win2k AD domain account password. The account doesn't even need to have the ability to log in locally to the Linux machine. It does have to exist however and it must have the proper permissions to the directories you are sharing out with Samba for the user to access them. This hasn't changed from Samba 2.2
To get around the need for for local Linux accounts, you need to use winbindd. It'll be interesting to see how that will work in conjuction with an AD domain. But that's another subject.