Windows 2003 Active Directory Setup:dcpromo

Windows 2003 Active Directory Setup:dcpromo

Now that we have setup Windows Server 2003 on our virtual machine, and we have patched it with SP2, Installed an Antivirus and setup DNS, is time now to setup active directory using dcpromo. Read about how to install and configure DNS on Windows Server 2003 from my previous post.

Setting up active directory using the run command dcpromo is a straightforward procedure. To begin, from your windows 2003 server desktop go to Start click on Run and type dcpromo and hit Enter.


The “Welcome to the Active Directory Installation Wizard” should come up:





Click on Next. On the following window, you will get a warning about comparability issues with other Operating Systems. Improve security settings in Windows Server 2003 affect older versions of windows:





After reading and thinking about consequences, click Next. On the next screen, you will get two options. The first option asks you if you want the server to become a domain controller for a new domain or if you want the server to be an additional domain controller for for an existing domain:



Select the first option and click Next. On the next window, you will get three options. the first option is to setup the domain in a new forest. Select this option if its the first domain controller on your organization, or if you want it to be totally independent from any forest.

Option two: Child domain in an existing domain tree. select this option if you want the domain to be a child domain from an existing domain. option three: Domain tree in an existing forest. if you don’t want any of the above, select this option.





In our case, choose the first option, and click Next. On the next screen, we need to type the full DNS name for the new domain:



Type the full DNS name like helpdeskgeek.com, and click on Next. On the next screen, we need to choose the NETBIOS name. This is the name earlier version of windows users will be using to identify the new domain.





Choose the name, and click Next. On the next screen, you need to select the location of where you want to store the database and log files. for best performance store them in separate disks



Choose the location where you want the active directory database and logs, and click Next.

Next, the Shared system volume window will come up. here, you need to choose the location on where you want to store the SYSVOL files. this folder contains the domain public files and are replicated to all the domain controllers in the domain.





Choose the folder location, and click Next. On the next window, the DNS registration diagnostic will show up. in here most likely you will get ” Diagnostic failed” and will give you three options. First option: it will allow you to perform the DNS diagnostic again,if you have corrected the problem.

Option two: it gives you the option to allow the active directory wizard to install and configure DNS for you, and use this DNS as the primary DNS for this server. third option, it allows you to bypass this window if you plan to correct the problem later on.





Even though we have already installed DNS on this server, we have not configure any of its services, so we will choose the option to Install and configure DNS server on this computer and set this computer to use this DNS server as its preferred DNS server. then click Next.

On the next window, you need to choose what type or permissions you want for users and group objects. Here you will get two options. the first options: select this option if you run server programs with pre-windows 2000. option two: select this option, if you only run windows servers 2000 and windows servers 2003 on your domain.





Select the second option, and click Next. On the next window, you need to enter the Directory services restore mode administrator password. This password is used when you start the computer in directory services restore mode. This account is different from the domain administrator account.





Type your chosen password, and click Next. Next, you will get the summary of all the options you have chosen during the active directory wizard. remember, the domain administrator account password is the same as the current local administrator password.



Click Next. the active directory installation should begin.



Some serious configuration processes going here. After a few minutes, active directory should be installed.





Click on Finish. and restart the computer. Active Directory should be now installed.

Integrating Samba, Active Directory and LDAP

Abstract

I have stumbled onto a nice way to configure Samba to authenticate against AD, but use the UID/GID information from OpenLDAP.

History: how I got here

It is so frustrating to me that Microsoft's Authentication mechanism is totally incompatible with mechanisms available with OpenLDAP. When attempting to integrate Windows and Linux environments together, eventually you realize that there's currently no getting around having to store two password fields, one for windows type authentication, another for linux type authentication.

For me, I distrust Microsoft to the degree that I don't want to modify the AD schema to allow AD to store Linux information, and there's enough magic going on that I don't want to try to fool M$ into thinking that OpenLDAP is actually AD. I know both those options are technically possible, but, if I still have to store two password fields, then I might as well just deal with having to administer both AD and OpenLDAP; after all, most of the linux information is exclusive of the windows information and vice versa. The few overlapping areas aren't really of great concern to me; do I really care if their phone/address information is accurate? No, I care if they have appropriate access rights.

The Problem

So, I created OpenLDAP instance(s) to centralize Linux logins, and it is also used for authentication of internal web services like Open Fire IM, a Xoops Forum, Confluence, etc. AD is used for windows authentication.

Now we go to configure Samba, and we run straight into the problem. On the one hand, OpenLDAP contains the user's uid and gid numbers that we want Samba to recognize, but we can't authenticate a windows share using OpenLDAP, we have to use AD. But, an unmodified AD schema has no way to store the appropriate uid/gid numbers.

One potential solution is for Linux to run Winbind, which has the ability to map AD Security Identifiers (SID's) to uids and gids, but keeping such a table accurate would create time consuming and tedious administration tasks. It appears, we've got a catch 22 situation with no clean solution.

The Solution I stumbled upon

So, I began by configuring Kerberos, Samba and Winbind according to the Samba wiki but ignoring the PAM configuration because I don't want Linux login's to authenticate against AD. After setting things up as shown in the configuration areas below, but with winbind also configured, I discovered that when users mapped the Samba home directory, the uid/gid numbers that were being used were, in fact, coming from the OpenLDAP server, and was NOT the automatically generated SID/UID/GID mapping created by Winbind!

The username was identical in AD and OpenLDAP, and the OpenLDAP information in the nsswitch.conf file was listed first, so that's what was being used; I didn't need Winbind at all. So, I just removed the Winbind option from the /etc/nsswitch.conf and /etc/samba/smb.conf files altogether.

So, as long as the AD "user logon name", and OpenLDAP uid strings match for all the users that need linux logins and Samba mappings, you don't need to use winbind at all.

Why it works

Samba will authenticate against AD, and then utilize the normal 'getent' system calls to gather the uid/gid numbers, and those will come from OpenLDAP, and/or the local system files as configured within the nsswitch.conf file.

Prerequisites

• Linux server configured to use OpenLDAP for authentication
  • OpenLDAP server on the network
  • OpenLDAP client configured properly on the target server
  • Nss_LDAP configured properly on the target server
  • PAM configured properly on the target server
• Samba installed on the target server
• Kerberos installed on the target server

Kerberos Configuration

/etc/krb5.conf

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

[libdefaults]
 default_realm = DOMAIN.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

[realms]
 DOMAIN.COM = {
  kdc = dc1.domain.com:88
  admin_server = dc1.domain.com:749
  default_domain = domain.com
 }

[domain_realm]
 .domain.com = DOMAIN.COM
 domain.com = DOMAIN.COM

Configure nsswitch

/etc/nsswitch.conf

passwd:       files ldap
shadow:       files ldap
group:        files ldap

Samba Configuration

/etc/samba/smb.conf

[global]
        workgroup = DOMAIN
        server string = Samba Server Version %v

        security = ADS
        realm = DOMAIN.COM

        encrypt passwords = yes
        log level = 3
        log file = /var/log/samba/%U.log
        max log size = 50
        template shell = /bin/bash

[homes]
        comment = Home Directories
        browseable = no
        writable = yes
        force create mode = 0660
        force directory mode = 0770

Establish AD Connection

AD needs to have the machine register as a member of the AD domain, first initialize the Kerberos connection:

kinit 

You'll need to provide the appropriate password, then:

net ads join "Computers"

If successful it should return a notification that the computer was connect to Active Directory.

Start Samba Services

Service smbd start

Map a drive to the samba share

As an appropriate user logged into the AD domain, just type this at a windows command prompt:

net use : \\\homes