Skip to content

# fix wonky formatting #1426

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 18, 2023
Merged

# fix wonky formatting #1426

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
71 changes: 21 additions & 50 deletions docs/guides/security/authentication/active_directory_authentication.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,34 +12,23 @@ contributors: Steven Spencer, Sambhav Saggi, Antoine Le Morvan, Krista Burdine

## Introduction

Microsoft's Active Directory (AD) is, in most enterprises, the de facto
authentication system for Windows systems and for external, LDAP-connected
services. It allows you to configure users and groups, access control,
permissions, auto-mounting, and more.
In most enterprises, Microsoft's Active Directory (AD) is the default authentication system for Windows systems and for external, LDAP-connected services. It allows you to configure users and groups, access control, permissions, auto-mounting, and more.

Now, while connecting Linux to an AD cluster cannot support _all_ of the
features mentioned, it can handle users, groups, and access control. It is even
possible (through some configuration tweaks on the Linux side and some advanced
options on the AD side) to distribute SSH keys using AD.
Now, while connecting Linux to an AD cluster cannot support _all_ of the features mentioned, it can handle users, groups, and access control. It is possible (through some configuration tweaks on the Linux side and some advanced options on the AD side) to distribute SSH keys using AD.

This guide, however, will just cover configuring authentication against Active
Directory, and will not include any extra configuration on the Windows side.
This guide, however, will just cover configuring authentication against Active Directory, and will not include any extra configuration on the Windows side.

## Discovering and joining AD using SSSD

!!! Note

Throughout this guide, the domain name `ad.company.local` will be used to
represent the Active Directory domain. To follow this guide, replace it with
the actual domain name your AD domain uses.
The domain name `ad.company.local` throughout this guide will represent the Active Directory domain. To follow this guide, replace it with your AD domain's actual domain name.

The first step along the way to join a Linux system into AD is to discover your
AD cluster, to ensure that the network configuration is correct on both sides.
The first step along the way to join a Linux system into AD is to discover your AD cluster, to ensure that the network configuration is correct on both sides.

### Preparation

- Ensure the following ports are open to your Linux host on your domain
controller:
- Ensure the following ports are open to your Linux host on your domain controller:

| Service | Port(s) | Notes |
|----------|-------------------|-------------------------------------------------------------|
Expand All @@ -48,10 +37,10 @@ AD cluster, to ensure that the network configuration is correct on both sides.
| LDAP | 389 (TCP+UDP) | |
| LDAP-GC | 3268 (TCP) | LDAP Global Catalog - allows you to source user IDs from AD |

- Ensure you have configured your AD domain controller as a DNS server on your
Rocky Linux host:
- Ensure you have configured your AD domain controller as a DNS server on your Rocky Linux host:

**With NetworkManager:**

```sh
# where your primary NetworkManager connection is 'System eth0' and your AD
# server is accessible on the IP address 10.0.0.2.
Expand All @@ -61,6 +50,7 @@ AD cluster, to ensure that the network configuration is correct on both sides.
- Ensure that the time on both sides (AD host and Linux system) is synchronized (see chronyd)

**To check the time on Rocky Linux:**

```sh
[user@host ~]$ date
Wed 22 Sep 17:11:35 BST 2021
Expand All @@ -75,8 +65,7 @@ AD cluster, to ensure that the network configuration is correct on both sides.

### Discovery

Now, you should be able to successfully discover your AD server(s) from your
Linux host.
Now, you should be able to successfully discover your AD server(s) from your Linux host.

```sh
[user@host ~]$ realm discover ad.company.local
Expand All @@ -94,15 +83,11 @@ ad.company.local
required-package: samba-common
```

This will be discovered using the relevant SRV records stored in your Active
Directory DNS service.
This will be discovered using the relevant SRV records stored in your Active Directory DNS service.

### Joining

Once you have successfully discovered your Active Directory installation from
the Linux host, you should be able to use `realmd` to join the domain, which
will orchestrate the configuration of `sssd` using `adcli` and some other such
tools.
Once you have successfully discovered your Active Directory installation from the Linux host, you should be able to use `realmd` to join the domain, which will orchestrate the configuration of `sssd` using `adcli` and some other such tools.

```sh
[user@host ~]$ sudo realm join ad.company.local
Expand All @@ -114,8 +99,7 @@ If this process complains about encryption with `KDC has no support for encrypti
[user@host ~]$ sudo update-crypto-policies --set DEFAULT:AD-SUPPORT
```

If this process succeeds, you should now be able to pull `passwd` information
for an Active Directory user.
If this process succeeds, you should now be able to pull `passwd` information for an Active Directory user.

```sh
[user@host ~]$ sudo getent passwd [email protected]
Expand All @@ -137,8 +121,7 @@ [email protected]:*:1450400500:1450400513:Administrator:/home/admin

### Attempting to Authenticate

Now your users should be able to authenticate to your Linux host against Active
Directory.
Now your users should be able to authenticate to your Linux host against Active Directory.

**On Windows 10:** (which provides its own copy of OpenSSH)

Expand All @@ -152,19 +135,13 @@ Last login: Wed Sep 15 17:37:03 2021 from 10.0.10.241
[[email protected]@host ~]$
```

If this succeeds, you have successfully configured Linux to use Active
Directory as an authentication source.
If this succeeds, you have successfully configured Linux to use Active Directory as an authentication source.

### Setting the default domain

In a completely default setup, you will need to log in with your AD account by
specifying the domain in your username (e.g., `[email protected]`). If
this is not the desired behavior, and you instead want to be able to omit the
domain name at authentication time, you can configure SSSD to default to a
specific domain.
In a completely default setup, you will need to log in with your AD account by specifying the domain in your username (e.g., `[email protected]`). If this is not the desired behavior, and you instead want to be able to omit the domain name at authentication time, you can configure SSSD to default to a specific domain.

This is actually a relatively simple process, and just requires a configuration
tweak in your SSSD configuration file.
This is actually a relatively simple process, and just requires a configuration tweak in your SSSD configuration file.

```sh
[user@host ~]$ sudo vi /etc/sssd/sssd.conf
Expand All @@ -173,20 +150,15 @@ tweak in your SSSD configuration file.
default_domain_suffix = ad.company.local
```

By adding the `default_domain_suffix`, you are instructing SSSD to (if no
other domain is specified) infer that the user is trying to authenticate as a
user from the `ad.company.local` domain. This allows you to authenticate as
something like `john.doe` instead of `[email protected]`.
By adding the `default_domain_suffix`, you are instructing SSSD to (if no other domain is specified) infer that the user is trying to authenticate as a user from the `ad.company.local` domain. This allows you to authenticate as something like `john.doe` instead of `[email protected]`.

To make this configuration change take effect, you must restart the
`sssd.service` unit with `systemctl`.
To make this configuration change take effect, you must restart the `sssd.service` unit with `systemctl`.

```sh
[user@host ~]$ sudo systemctl restart sssd
```

In the same way, if you don't want your home directories to be suffixed by the domain name,
you can add those options into your configuration file `/etc/sssd/sssd.conf`:
In the same way, if you don't want your home directories to be suffixed by the domain name, you can add those options into your configuration file `/etc/sssd/sssd.conf`:

```
[domain/ad.company.local]
Expand All @@ -198,8 +170,7 @@ Don't forget to restart the `sssd` service.

### Restrict to certain users

There are various methods to restrict access to the server to a limited list of users,
but this, as the name suggests, is certainly the simplest:
There are various methods to restrict access to the server to a limited list of users, but this, as the name suggests, is certainly the simplest:

Add those options into your configuration file `/etc/sssd/sssd.conf` and restart the service:

Expand Down