What is active directory linux

Ubuntu Documentation

Introduction

Active Directory from Microsoft is a directory service that uses some open protocols, like Kerberos, LDAP and SSL.

There are several ways to use AD for authentication, you can use Centrify Express, Likewise Open, pam_krb5, LDAP or winbind. For Centrify Express see [DirectControl]. Centrify Express can be used to integrate servers or desktops with Active Directory. Likewise Open is also a solution for Linux workstations to authenticate to an Active Directory domain. For Likewise Open see [LikewiseOpen] or Likewise Open. For Winbind see [ActiveDirectoryWinbindHowto].

The purpose of this document is to provide a guide to configuring Samba on Ubuntu to act as a file server in a Windows environment integrated into Active Directory. The goal is to create a file server that is as close to a one to one replacement for a Microsoft Windows file server as possible from the client’s perspective.

Background

It is important to keep in mind that the Samba developers have to play detective to try to basically reverse engineer the Microsoft implementation of the SMB protocol. The end result is that there are occasional issues that must be worked around if a bug fix does not exist. With the instructions below, expected behavior should be acceptable in most corporate environments.

Samba allows for a great deal of flexibility in how shares behave on a per-share basis. It is outside the scope of this document to cover each configuration setting and how they behave. It would be very beneficial to first read the smb.conf documentation found at the Samba web page. There are quite a few settings in the documentation, but getting a general feel of what they are and what they do will help in understanding this document and how you can take a step beyond by changing settings for your own tastes and environment.

Prerequisites

Security updates need to be enabled for not only the main repository, but for the universe repository as well (as now documented below). If this is not done, any security updates for the main (supported) packages create failed dependencies for the relevant universe packages.

Here is the list of prerequisites specific to this document:

• Ubuntu Server Edition default installation.
• Windows 2003 Native Domain (mixed-mode not tested, but may work)
• Ample hard drive space to accommodate packages and shares.
• Proper IP DNS settings configured so that internal names can be resolved.

Installation

Install the samba, acl, and attr packages if you wish to enable extended attributes which enable a greater level of control for file Access Control Lists. See InstallingSoftware for information regarding Package Managers and installing packages.

You can edit /etc/fstab similar to the following to enable extended attributes on boot:

Then remount the filesystem:

Kerberos

The first step in joining an Active Directory domain is to install and configure Kerberos. See Samba/Kerberos for details.

After Kerberos has been installed and configured, the authentication system (PAM) needs to be configured to use Active Directory. Edit /etc/pam.d/common-auth and add:

Then edit /etc/pam.d/common-session:

kpasswd for password changing works, but note that AD by default disallows users from changing passwords more than once a day.

The users from AD have to exist in /etc/passwd on the Ubuntu workstation, you can also use libnss-ldap to get the account info from AD.

TestQuery: Windows

Assuming you do not maintain the Active Directory you will want to determine the structure of AD before trying to connect to it from Linux. From a windows PC connected to AD you should perform a query using Microsoft’s Active Directory Application Mode (ADAM). ADAM is a package of tools that includes CSVDE, which we will be using to perform our queries.

NB ADAM is not supported on Windows 7, and has been replaced by AD LDS.

Type this into Google, the download page should be the second hit.

Install. Open the command prompt. Start > RUN and type ‘cmd’ Navigate to the installation directory, default is c:\windows\ADAM

Example Queries: Query a user entry

wildcards work as well

Query a computer entry

Return everything in the following AD folder

The output of these queries would be placed within export.csv inside c:\windows\ADAM. Which can then be viewed as a spreadsheet editor.

For more on querying with ADAM’s CSVDE [www.computerperformance.co.uk/Logon/Logon_CSVDE.htm]

Configure AD

In Windows Server versions prior to WS03 R2, it is necessary to extend the LDAP schema from AD with the UNIX attributes. Install «Windows Services for UNIX» from Microsoft (I used version 3.5). SFU: http://www.microsoft.com/windows/sfu/

Installing SFU 3.5 on Windows Server 2003 (non R2) does not appear to add the necessary LDAP schema extensions.

In order to extend the LDAP schema, it is necessary to install the «Server for NIS» component. The installation needs to be performed using an account that has Enterprise Admin privileges in order for the schema to be extended successfully (indeed, Enterprise Admin privileges are required even if the schema has already been extended). In Active Directory, schema extensions are non-reversible, so if the NIS Server is not required, it can be removed once the schema extension is complete. If the SFU Server for NIS is installed however, it will extend the Active Directory Users and Computers tool with a UNIX Attributes tab which allows GUI editing of the UNIX attributes for users, groups and computers.

In Windows Server 2003 R2, the Active Directory schema is already extended with an RFC2307-compliant schema. This differs from the schema extensions used in SFU3.5, requiring a different libnss-ldap configuration. It is still necessary to install Server for NIS to extend the Active Directory Users and Computers tool with the UNIX Attributes tab to allow GUI editing of UNIX attributes for users, groups and computers.

TestQuery: Linux

We will want to perform a testquery in Linux before we attempt to configure AD. It is much simpler to determine how to connect on the command line and then configure rather than reconfigure a file repeatedly.

We will need at least these two packages to perform test queries on Active Directory.

We perform queries with ‘ldapsearch’ We must specify these minimum parameters:

We need to specify the LDAP Server (Domain Controller)

and the authentication type: simple or SASL

If we have an active directory account and proper libraries installed, you can also authenticate using SASL-GSSAPI, and you will not need -D or -W options

SASL authentication off, simple on

and the folder we want to search in

and who to authenticate as

we’ll have it prompt for the password, instead of specifying it in the command

and lets search for sammy’s account

One doesn’t need to worry about spaces, but to specify a comma as part of the path we need to prefix the comma with ‘\\’

libnss-ldap

You can install libnss-ldap and nscd from the Universe Repository.

Now you need to set up /etc/nsswitch.conf for ldap.

If you have trouble when you attempt to ping and your network has a wins server you will want to append ‘wins’ to the hosts line of nsswitch.conf — you may only notice this only when you try to ping a static IP Linux PC from another Linux PC — I believe WINS is a part of the samba package and the IP addresses for WINS servers are stored in /etc/samba/dhcp.conf, the static IP machine also needs to specify its NetBIOS name within /etc/samba/smb.conf

When fiddling with /etc/nsswitch.conf, it is best to turn the Name Services Caching Daemon off — /etc/init.d/nscd stop or you will be confused by cached results. Turn it on afterwards.

Then you need to set up /etc/libnss-ldap.conf. AKA: /etc/ldap.conf

I think it only needs rootbinddn, no binddn, with the bindpw in /etc/libnss-ldap.secret, not here. I have also successfully combined /etc/ldap/ldap.conf, /etc/libnss-ldap.conf, and /etc/pam_ldap.conf, symlinking them all to /etc/ldap/ldap.conf — AndyRabagliati

Incorrect nss_map settings will prevent one from authenticating and reading AD in general. These settings are dependent on the column names within your AD database. In older systems the database (schema) needs to be extended as described in the ‘Configure AD’ section. Once these *NIX attributes are part of the schema they can be modified with the MMC snap-in Active Directory Users and Groups, as long as idmu.exe has been installed from the Windows Server 2003 R2 Administration Tools Pack. If *NIX group membership has been administered by modifying the list in the UNIX attributes tab of AD Users and Computers (which is REQUIRED in a NIS environment), then ‘uniqueMember’ should be mapped to ‘msSFU30PosixMember’ (or ‘posixMember’ for WS03R2) as ‘member’ only includes the membership listed in the Windows group. For Windows Server 2003 R2, the schema extensions are RFC2307 compliant — no longer prefixed ‘msSFU30’ and with the next letter in lower case (e.g. msSFU30UidNumber is now uidNumber).

If you are in a complex environment with multiple domains or multiple trees and want people from all your domains to login specify the Global Catalog port for your LDAP queries instead of the default port. If you do this is essential all LDAP servers specified in the ldap.conf be Global Catalogs. If you can create a DNS entry for your Global Catalogs of «ldap.company.com» then your URI becomes ldap://ldap.company.com:3268/. Using a DNS entry creates a dependancy on DNS but also allows you to add or remove Global Catalog servers with out having to edit the ldap.conf on each client. Taking this step also requires making all of the attributes you are using accessible via the Global Catalog LDAP service, many of the UNIX attributes are local to a specific domain. You can do this with the schema managment MMC. If you are using these attributes to authenticate your users (like UID) you may want to index them in Active Directory as well. Using the sAMAccountName gets around this since it’s already replicated to all Global Catalogs and indexed. If you have a large environment it’s very important to add proper filtering for your NSS lookups as shown below.

Further optimizations of the queries can be made for the nss_base properties:

These filters may be required if not all of your AD users and groups have had their Unix Attributes (UID, GID, etc) configured. Specifiying uidNumber=* will exclude AD objects that have not had this attribute set from the search. . If running «id -Gn » hangs (but getent passwd and getent group work correctly), then you should make these changes.The filters above will sort for users that are not computers (AD stores computers as User objects with a «$» at the end) and have a UID greater than or equal to 2000 and a Unix home directory specified. If you are not seeing what you expect work with out filters and using the default LDAP port and add complexity one step at a time.

The ampersand in the queries above merely specifies AND logic

Troubleshooting

To debug LDAP queries one should make sure nscd is off and use the getent command

To follow the actions of the command use strace

If thats not enough you can place a line in the configuration file for output:

This can be a value anywhere from 1 to 10, 10 being the most verbose.

With this config is the LDAP Traffic unencrypted and someone can sniff it. To make it secure use SSL

Now you need to set up /etc/pam.d/common-auth and

set up /etc/pam.d/common-account.

We are still using Kerberos for authentication, but now we are storing the information that would normally be stored in /etc/passwd using Active Directory.

Here are some other useful config files:

• login.defs
• nscd.conf
• /var/log/auth.log

Here is an alternative configuration example: Patched pam_krb5 to include support for directory service users]

Should this page be cleaned up? I think that it’s got a lot of older references in it (libnss-ldap.conf, SFU3.5, adam, older pam configs that are not required anymore, lots of ldapsearch stuff that really is more for troubleshooting than anything else and certainly not required. Maybe more of a cookbook way

ActiveDirectoryHowto (последним исправлял пользователь knome 2013-12-14 11:32:55)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

Источник

Active Directory integration

This article or section needs expansion.

Active Directory (AD) is a directory service that Microsoft developed for Windows domain networks.

This article describes how to integrate an Arch Linux system with an existing Windows domain network using Samba.

Before continuing, you must have an existing Active Directory domain, and have a user with the appropriate rights within the domain to: query users and add computer accounts (Domain Join).

This document is not an intended as a complete guide to Active Directory nor Samba. Refer to the resources section for additional information.

Contents

Introduction

This article explains how to configure an Arch Linux system to participate in an Active Directory domain. This article was written and tested on a fresh installation, and it is assumed that all configuration files are in their unmodified, post-installation state. For the duration of the article, the example Active Directory domain will use the following configuration:

• NetBIOS domain name: INTERNAL
• DNS domain name: internal.domain.tld
• Kerberos realm: INTERNAL.DOMAIN.TLD
• First DC: server1.internal.domain.tld with IP address 192.168.1.1
• Second DC: server2.internal.domain.tld with IP address 192.168.1.2

In most small networks, the DCs (domain controllers) also hold the DNS server role. This may not be true in larger networks. Generally, DCs also hold the NTP role, but not always. Consult your network administrator to verify correct values for DNS and NTP servers.

Needed software

In order to use samba effectively, you will need to install the following packages: samba , smbclient , and ntp . (timedatectl can be used as an alternative to ntp.)

Additionally, while not required, the following packages will be useful for testing and troubleshooting: bind , krb5 , and if a printing is desired (whether you want to share printers, or use printers on another Samba/Windows host), cups .

Initial configuration of services

DNS configuration

Active Directory depends entirely on DNS for name resolution. It is imperative that the /etc/resolv.conf file is configured with both the correct DNS servers and a domain search suffix. Whether configured via DHCP or static configuration, ensure that these values are correct for your domain. For the example domain configuration, the following contents are appropriate (be sure to replace 192.168.1.1, 192.168.1.2, and internal.domain.tld with appropriate values for your network):

If you elected to install the bind package, you can test DNS configuration with the following commands (be sure to replace server1 and internal.domain.tld with appropriate values for your network):

You should get output similar to the following (adjust appropriately for only one DC, or more than two):

NTP configuration

In an Active Directory domain, more specifically for Kerberos ticketing, it is imperative that time is synchronized will all other hosts on the network. A margin of error no more than five minutes is required. For the example domain configuration, an appropriate /etc/ntp.conf file should have the following contents (be sure to replace server1, server2, and internal.domain.tld with appropriate values for your network):

Enable and start the ntpd.service unit.

Kerberos configuration

The Samba documentation recommends a minimal Kerberos configuration, with just enough information in the [libdefaults] section to hand off the work of discovering domain details to DNS. Unfortunately, this does not work well in practice. Continuing with the example domain configuration, modify the /etc/krb.conf file with the following contents (be sure to replace instances of INTERNAL, internal.domain.tld, SERVER1, and INTERNAL.DOMAIN.TLD with appropriate values for your network):

Samba configuration

Base Samba configuration file

A default installation of samba does not ship with an example /etc/samba/smb.conf file. For our example domain configuration, use the following base settings (replace instances of INTERNAL and INTERNAL.DOMAIN.TLD with appropriate values for your network):

If you do not wish to share local printers configured in cups , then add the following to the [Global] section of the /etc/samba/smb.conf file:

The remainder of the configuration depends on whether your domain supports RFC2307 Unix/NFS Attributes. Consult with your domain administrator if unsure.

Adding the idmap configuration for domains with RFC2307 extensions

Be certain that the values below do not overlap with system values, and that all users have at least the uidNubmer attribute, and that those users’ PrimaryGroup has a gid attribute. Append to the following to the the [Global] section of the /etc/samba/smb.conf file (replace INTERNAL with the NetBIOS domain name):

Additionally, if user accounts in AD have a gidNumber attribute, you can use it instead of the RID for the user’s Primary Group by appending the following setting (again in the [Global] section):

Adding the idmap configuration for domains without RFC2307 extensions

If your administrator has not extended the AD schema to include the RFC2307 attributes, use the following idmap configuration in the [Global] section of the /etc/samba/smb.conf file (replace INTERNAL with the NetBIOS domain name):

Joining the domain

To join the AD domain, simply issue the following command (be sure to replace Administrator with a user that has privileges to join the AD domain).

Start the individual Samba services

Enable and start the smb.service , nmb.service , and winbind.service services.

Configure NSS

Modify the /etc/nsswitch.conf file to allow Samba to map names to uid and gid:

Testing NSS

Verify connectivity by listing the AD domain users and groups that system is aware of:

You should get a list of AD users followed by AD groups.

Configuring PAM authentication

Rather than configuring options directly in the Linux-PAM configuration files, set defaults for the pam_winbind module in /etc/security/pam_winbind.conf :

For most services, it will be sufficient to modify only the /etc/pam.d/system-auth file. Any configuration for programs that do not include this file will also need to be modified directly. Create a backup of the /etc/pam.d/system-auth file and use the following configuration:

If you have other services that do not include the /etc/pam.d/system-auth file, modify the configuration to mirror all pam_unix.so entries for pam_winbind.so and change all required to sufficient. A good example is the su configuration. Create a backup of the /etc/pam.d/su file and use the following in its place:

The above pam_winbind configuration will not use the default location of the Kerberos ticket ( KRB5CCNAME ), which is at /tmp/krb5cc_UID . Instead, it stores the automatically refreshed Kerberos ticket to /run/user/UID/krb5cc . Append the following to your krb5.conf to let Kerberos know your new location:

To test your changes, start a new console or ssh session (do not exit your existing session until you have tested thoroughly) and try to login using the AD credentials. The domain name is optional, as this was set in the Winbind configuration as ‘default realm’. Please note that in the case of ssh, you will need to modify the /etc/ssh/sshd_config file to allow kerberos authentication (see below).

Run klist to verify that you have received a kerberos ticket. You should see something similar to:

Finally, you should test login as both the root user and a local unprivileged user before logging out of your existing (working) session.

Old Wiki Article

Active Directory serves as a central location for network administration and security. It is responsible for authenticating and authorizing all users and computers within a Windows domain network, assigning and enforcing security policies for all computers in a network and installing or updating software on network computers. For example, when a user logs into a computer that is part of a Windows domain, it is Active Directory that verifies his or her password and specifies whether they is a system administrator or normal user. Server computers on which Active Directory is running are called domain controllers.

Active Directory uses Lightweight Directory Access Protocol (LDAP) versions 2 and 3, Microsoft’s version of Kerberos and DNS.

Terminology

If you are not familiar with Active Directory, there are a few keywords that are helpful to know.

• Domain : The name used to group computers and accounts.
• SID : Each computer that joins the domain as a member must have a unique SID or System Identifier.
• SMB : Server Message Block.
• NETBIOS: Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
• WINS: Windows Information Naming Service. Used for resolving Netbios names to windows hosts.
• Winbind: Protocol for windows authentication.

Active Directory configuration

This section works with the default configuration of Windows Server 2012 R2.

GPO considerations

Digital signing is enabled by default in Windows Server, and must be enabled at both the client and server level. For certain versions of Samba, Linux clients may experience issues connecting to the domain and/or shares. It’s recommended you add the following parameters to your smb.conf file:

If that is not successful, you can disable Digital Sign Communication (Always) in the AD group policies. In your AD Group Policy editor, locate:

Under Local policies > Security policies > Microsoft Network Server > Digital sign communication (Always) activate define this policy and use the disable radio button.

If you use Windows Server 2008 R2, you need to modify that in GPO for Default Domain Controller Policy > Computer Setting > Policies > Windows Setting > Security Setting > Local Policies > Security Option > Microsoft network client: Digitally sign communications (always).

Please note that disabling this GPO affects the security of all members of the domain.

Linux host configuration

The next few steps will begin the process of configuring the Host. You will need root or sudo access to complete these steps.

Installation

Install the following packages:

Updating DNS

Active Directory is heavily dependent upon DNS. You will need to update /etc/resolv.conf to use one or more of the Active Directory domain controllers:

Replacing and with valid IP addresses for the AD servers. If your AD domains do not permit DNS forwarding or recursion, you may need to add additional resolvers.

Configuring NTP

Read System time#Time synchronization to configure an NTP service.

On the NTP servers configuration, use the IP addresses for the AD servers, as they typically run NTP as a service. Alternatively, you can use other known NTP servers provided the Active directory servers sync to the same stratum.

Ensure that the service is configured to sync the time automatically very early on startup.

Kerberos

Let us assume that your AD is named example.com. Let us further assume your AD is ruled by two domain controllers, the primary and secondary one, which are named PDC and BDC, pdc.example.com and bdc.example.com respectively. Their IP adresses will be 192.168.1.2 and 192.168.1.3 in this example. Take care to watch your syntax; upper-case is very important here.

Creating a Kerberos ticket

Now you can query the AD domain controllers and request a kerberos ticket (uppercase is necessary):

You can use any username that has rights as a Domain Administrator.

Validating the Ticket

Run klist to verify you did receive the token. You should see something similar to:

pam_winbind.conf

If you get errors stating that /etc/security/pam_winbind.conf was not found, create the file and add the following:

With this setup, winbind will create user keytabs on the fly (krb5_ccache_type = FILE) at login and maintain them. You can verify this by simply running klist in a shell after logging in as an AD user but without needing to run kinit. You may need to set additional permissions on /etc/krb5.keytab eg 640 instead of 600 to get this to work (see FS#52621 for example)

Samba

Samba is a free software re-implementation of the SMB/CIFS networking protocol. It also includes tools for Linux machines to act as Windows networking servers and clients.

In this section, we will focus on getting Authentication to work first by editing the ‘Global’ section first. Later, we will go back and add shares.

Join the domain

You need an AD Administrator account to do this. Let us assume this is named Administrator. The command is ‘net ads join’

Starting and testing services

Starting Samba

Hopefully, you have not rebooted yet! Fine. If you are in an X-session, quit it, so you can test login into another console, while you are still logged in.

Enable and start the individual Samba daemons smbd.service , nmbd.service , and winbindd.service .

Next we will need to modify the NSSwitch configuration, which tells the Linux host how to retrieve information from various sources and in which order to do so. In this case, we are appending Active Directory as additional sources for Users, Groups, and Hosts.

Testing Winbind

Let us check if winbind is able to query the AD. The following command should return a list of AD users:

• Note we created an Active Directory user called ‘test.user’ on the domain controller

We can do the same for AD groups:

Testing nsswitch

To ensure that our host is able to query the domain for users and groups, we test nsswitch settings by issuing the ‘getent’ command.

The following output shows what a stock ArchLinux install looks like:

Testing Samba commands

Try out some net commands to see if Samba can communicate with AD:

Configuring PAM

Now we will change various rules in PAM to allow Active Directory users to use the system for things like login and sudo access. When changing the rules, note the order of these items and whether they are marked as required or sufficient is critical to things working as expected. You should not deviate from these rules unless you know how to write PAM rules.

Источник