Difference between revisions of "Active Directory Integration"

From ArchWiki
Jump to: navigation, search
m (Installation of windows :<br>)
Line 58: Line 58:
== Installation of windows :<br> ==
== Installation of windows :<br> ==
<p>To succed in this, We have to make some small changes in the Active Directory:
<p>To succed in this, We have to make some small changes in the Active Directory:
* GåGo to Start > Administrative tools > Domain Controllers Security Policies
* Go to Start > Administrative tools > Domain Controllers Security Policies
*Find in there - Local policies > Security policies > Mikrosoft Network Server. Digitalt signeer kommunikation (Allways)- Activate "define this policyand disable the radiobutton - push Apply and then OK</p>
*Find in there - Local policies > Security policies > Mikrosoft Network Server. Digitalt signeer kommunikation (Allways)- Activate "define this policyand disable the radiobutton - push Apply and then OK</p>
<p> Now on to the exiting part of it all  - the Linux machine. </p>
<p> Now on to the exiting part of it all  - the Linux machine. </p>
== Installation of Linux :<br> ==
== Installation of Linux :<br> ==
=== Kerberus - krb5.conf :<br> ===
=== Kerberus - krb5.conf :<br> ===

Revision as of 15:06, 24 November 2006

HOWTO Arch Linux Server in a Windows-domain:

This guide explains howto setup an Arch Linux server into an existing Windows domain.


This can be the solution in some networks,where windows server licens are pretty expensive,so here is a solution on what you have to do to make an Arch server be acceptet into a existing Windows domain.

The meaning with this are, that you can use an LDAP/AD to validate your users password, no matter if you are using your windows or Linux machine.. Later on hopefully some others will help to make the changes so you can change your passwords on any given machine.

Lucky for us Linux uses the same services that Windows uses:

  • Name Service Switch(NSS).
  • Pluggable Authentication Module(PAM)
  • Winbind together with Samba. Winbind servicen uses Samba's configuration to integrate with AD. Therefor you shall use Samba 3.05 or newere.
  • Kerberus. Winbind uses Kerberus to get the tickets to get access to AD. An Windows Domain Controller

    acts like a Key Distrubtions Center.

There is 2 alternative ways to do this - I have choose only to show one, but just menchion the other " just in case":

  • Use Kerberus Klient( Demands Active Directory)
  • Use windbind and Samba klient.


Requirements to get this to work is:

  • 1 Windows 2003 server with a running AD

The following services should be running on this machine:

    • Identity Manager for Unix-maskiner
    • DNS
    • Windows 2003 server tools
    • Windows 2003 server resource tools

On the Arch Linux machine: (The Distro does not matter aside from config file locations)

  • A running Arch Linux installation

  • A Windows machine to run test from.
  • Administrator access on all machines
  • Domain administrative rigths on AD

When all these demands are fullfiled, its time to start the installation:
There´s no need to configure OpenLDAP - BUT AD-support will not be compilet into SambaUnless Open-LDAP is installed.

Installation :

These packages are needed on the Arch machine:

  • Samba
  • Kerberus
  • NTP

we´re starting to install those by using pacman:

  • pacman -Sy samba
  • pacman -Sy ntp

Now is the needed packages installed and we can go on to the windows machine.

Installation of windows :

To succed in this, We have to make some small changes in the Active Directory:

  • Go to Start > Administrative tools > Domain Controllers Security Policies
  • Find in there - Local policies > Security policies > Mikrosoft Network Server. Digitalt signeer kommunikation (Allways)- Activate "define this policyand disable the radiobutton - push Apply and then OK

Now on to the exiting part of it all - the Linux machine.

Installation of Linux :

Kerberus - krb5.conf :

Configurate the file /etc/krb5.conf as following.We´re here counting on that our domain is called TEST.DK in the AD

# This is made to get this server to work under the domain TEST.DK  
default_realm = pdc.test.dk
clockskew = 300
ticket_lifetime = 1d
kdc = pdc.test.dk
kdc = pdc.test.dk:88
admin_server = pdc.test.dk:749
# v4_instance_convert = {
# kerberos = kerberos
# computer = computer.some.other.domain
# }
# } 

.test.dk = pdc.test.dk
test.dk = pdc.test.dk 

kdc = FILE:/var/log/kdc.log 
kadmin = FILE:/var/log/kadmin.log 

pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 0
debug = false

WARNING: Don´t changeyour domainname to other thing that TEST.DK (The name in AD) before you´re shure on what you´re doing. It should be the domain name you´re PDC is running with

P.S. your tickets is in use in this defined time, as defined above .

Now you shall edit the file /etc/hosts - So the machine knows where your pdc is no matter what.

192.168.X.X PDC.TEST.DK

Now you can request a ticket with the following command :

# kinit ADMINISTRATOR@UDBY.DK < Yes - it should be like this

You´ll now be asked for the password as shown above: - if its the correct password – you´ll be returned to the konsol, wich means this works. There can be a problem about the clock on the machines – Therefor its important that the time is the same on both machines. To avoid this, the time can be syncronised with this command:

# /usr/bin/ntpdate pdc.test.dk > This asks the Arch to syncronice with the time on PDC.

You can also edit your /etc/ntp.conf like this:

restrict default noquery notrust nomodify
restrict mask
fudge stratum 3
driftfile /etc/ntp.drift
logfile /var/log/ntp.log

Now you have told your machines with machine its allowed to update time from.

PAM (login) :

Now we have to change /etc/pam.d/login so it sends its request to PDC. So to chack a users name and passwd it sends a request to PDC:

auth    required        /lib/security/pam_securetty.so
auth    required        /lib/security/pam_nologin.so
auth    sufficient      /lib/security/pam_unix.so shadow md5 nullok likeauth
auth    required        /lib/security/pam_krb5.so use_first_pass

account required        /lib/security/pam_unix.so

password        required        /lib/security/pam_cracklib.so
password        required        /lib/security/pam_unix.so shadow md5 nullok use_authtok

session required        /lib/security/pam_unix.so
session optional        /lib/security/pam_krb5.so
session optional        /lib/security/pam_console.so

Now it should all work in theory, so if you try to log in to your server, you should use username and passwd.

Samba Configuration :

In here you can make a lot of strange things – So its a good thing to start reading at http://us3.samba.org/samba/ where you can get a lot of info about this. Here is what my smb.conf looks like:

netbios name = Atlantis
workgroup = TEST
realm = TEST.DK
server string = Atlantis
map to guest = Bad User
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
winbind gid = 10000-20000
winbind separator =+
os level = 20

# Theres no shell defined for users in AD, so I define a default shell to use
# Not sure if its even possible to define a shell in AD
template shell = /bin/bash

# Er sat til dette som default
; encrypt passwords = yes

# I denne "mode", vil Samba opføre sig som et medlem af domæne i et AD's realm. For at operere i denne "mode"
# skal maskinen der kører Samba have Kerberus installeret og konfigureret (/etc/krb5.conf) og dermed vil Samba
# tvinges til at joine AD's realm ved hjælp af internettet.
security = ads
password server = 192.168.X.X
preferred master = no
dns proxy = no
wins server = 192.168.X.X
wins proxy = no

# This should not be nessesary - BUT ???? 
admin users = @"NET+domain admins"

# secures that Samba only is listening to the cluster-service
interfaces =
bind interfaces only = yes

load printers = no
debug level = 3
use sendfile = no

comment = User´s homedirs
path =/home/%U
# valid users = %S net+%S
browseable = no
read only = no

# Find ud af om disse er nødvendige  
force group = "NET+domain admins"
inherit acls = Yes
map acl inherit = Yes

# Accepts the users to change their rigths 
acl group control = yes

comment = Data
valid users = %S net+%S
path = /data
read only = no
browseable = yes

comment = Backup filer
path = /backup
read only = no
browseable = yes
valid users = @"NET+Domain Admins"

You can run a test if your configuration is good enough.

# testparm<pre>
Fix the errors and restart samba
<pre># /etc/rc.d/samba restart 

We shall now explain to Samba that it shall use the PDC´s database about the users.Here are we using winbind wich is a part of samba´s suite.Winbind maps the UID and GID in the PDC over on our Linux-machine. Winbind uses a Unix-implementation of RPC-calls,Pluggable Authentication Module(PAM) and Name Service Switch(NSS) to allowe windows domain and users to access and grant permissions on the Linux-machine. The best part of winbind is, that you don´t have to define the mapping yourself, but only define a range of UID and GID. That´s what we defined in smb.conf. You shall edit /etc/nsswitch.conf . Only the to lines as shown here:

passwd:            compat winbind
shadow:            compat winbind
group:             compat winbind

Note: nsswitch is a part of glib-package – be shure that changes is not updating – eller or remember to change it back. Else you´ll have big problems later on. Registrate your configurations and remember those with this command:

wbinfo ----seth-auth-user=UDBY\\administrator%password

Testing :

We can now test on several ways: First a test of Samba and Winbind conf:

/etc/rc.d/samba restart

for some paranoids friends – we can test if winbinds is running correctly:

ps -aux | grep winbind

To test if we can get the info out of the PDC –

/usr/bin/wbinfo -u     eller wbinfo -u

We should not have a printet list of users in the PDC. We can do the same with our groups:

/usr/bin/wbinfo -g   eller wbinfo -g

We can use getent commands to get both the locale and the PDc userlist. These opetunities will generate a list of data – as /etc/passwd and /etc/group. It a good idea to test if AD´s users is valid on our Linux-server:

touch testfile $ chown ”UDBY+Guest” testfile

If this works – Welldone – Then there´s no more problems.

Samba Server on the domain :

Some good commands !

# net ads info
LDAP server: 192.168.X.X
LDAP server name: win2003
Realm: TEST.DK
Bind Path: dc=TEST,dc=DK
LDAP port: 389
Server time: Wed, 01 Mar 2006 14:59:44 GMT
KDC server: 192.168.X.X
Server time offset: -7

# net ads lookup
# net ads status

Lets get on to the last part - to registrate our Linux-server on our Windows-domain

# net ads join -U Administrator
Administrator's password:
Using short domain name -- TEST
Joined 'MASKIN-NAVN' to realm 'TEST.DK'

To check if it all is happend in the correct way – jump to your PDC and look in the AD under computers. There shold now be a record of your machine. And last - to leave to domain - the command is :

# net ads leave
Removed 'MASKIN-NAVN' from realm 'TEST.DK'

More INFO:

Everything there is to know about Samba

Please feel free to comment this article - but if your edit this - PLEASE LET ME KNOW