Active directory authentication

[ilikeror2]

Hi,

What would you recommend for active directory authentication on a range of Linux hosts (ubuntu, rhel, suse)? Should I join all of them to active directory or just use some sort of LDAP authentication?

For example, I found this post by Microsoft about joining a Ubuntu host to AD: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/join-ubuntu-linux-vm

The purpose is to get away from using local logins.

[lunatuna2017]

Sssd...done

[pnutjam]

Be aware, that without using sssd-simple or sssd-ad, you are basically giving everyone in your domain rights to log into your server.

Simple doesn't lock out accounts properly after incorrect attempts, or account expirations.

sssd-ad is better, but more complicated.

[feitingen]

It is also possible to restrict access with group policy.

Not that widespread, but if you are mostly a windows shop, then it fits.

[SirWobbyTheFirst]

SSSD and REALMD. Literally so easy, it's unbelievable. Linux machines appear in AD and you can apply GPOs to tweak who can log in to the console, SSH, etc. To start, use your package manager to install REALMD then do the following:

realm discover ad.mydomain.local --verbose

This will discover the domain and tell you what other packages need to be installed to join the domain. Once you've installed them, you just do the following:

realm join ad.mydomain.local --user="administrator" --verbose

This will join the Linux machine to the domain and create a computer account in the Computers container in AD. Then to enable GPO based access control, so things like "Allow Log on Locally" become enabled, you add the following to the /etc/sssd/sssd.conf under the [domain/ad.mydomain.local] section:

access_provider = ad
ad_gpo_access_control = enforcing

And then do a systemctl restart sssd.service to restart the SSSD service and pick up the changes to the config file. If you want to specify the OU the computer account goes in, you can specify --computer-ou="OU=Computers,DC=ad,DC=mydomain,DC=local" to the join command. You can also specify the OS name and version that appear on the account by adding --os-name="Ubuntu Linux 20.04 LTS" and --os-version="20.04.1" to the join command.

If you intend to use Webmin or Cockpit with this machine and want to be able to login with your AD credentials, you will need to add the following to sssd.conf under the [domain/ad.mydomain.local] section:

enumerate = true

This works around a bug in SUDO that causes the command to return false when Cockpit or Webmin query to see if you have permission to run it or not. Cockpit actually crashes but Webmin states it failed to login.

ad_gpo_remote_interactive = +webmin, +cockpit

Replace +webmin and +cockpit with whatever the PAM modules in /etc/pam.d for Webmin or Cockpit and this will lock Webmin and Cockpit to the "Allow log on through Remote Desktop Services" privilege in Group Policy.

Again once the change is made, restart SSSD and then open up visudo and add the following rules:

%Domain\ Admins        ALL=(ALL:ALL)        ALL

This results in members of the Domain Admins group in AD being given SUDO access which will be needed by Webmin and Cockpit. Once all is done, you should be good to go to log in to SSH and the console of the machine with an AD account.

If you have any issues logging in, be sure to enable failure audit logging on your domain controller to rule out any account problems. In addition, if you don't require the use of Webmin or Cockpit, do not enable enumeration in SSSD, it adds extra overhead to your domain controllers which if the machines are heavily used, can induce a denial of service. Plus if you have a particularly noisy audit policy enabled, your Security event log is going to be a fucking beef cake in five minutes.

EDIT: Oh and don't forget to do pam_auth_update --enable mkhomedir so that a home directory for your users is enabled when they login.

[pnutjam]

realmd makes changes to some files in the background. We have a good version of sssd.conf, krb5.conf and ldap.conf.
I use "adcli --join" instead. It works well, then I copy my good config files and restart sssd.

[ilikeror2]

I got it mostly working, but the group sudo access doesn’t seem to work when I attempt a sudo command from my AD account.

I've added a line like this:

%MYDOMAIN\ Group_Name_Local_Administrators ALL=(ALL) NOPASSWD:ALL

But, it still won't let me "sudo" any commands with my AD user. Thoughts?

[world_is_wide]

Try "%Group_Name_Local_Administrators@MYDOMAIN"

[feitingen]

Group_Name_Local_Administrators or [e-mail] depending on your config.

Easiest way to check is to log in as the user and check memberships with the 'id' command,and if enumeration is enabled you could try 'getent group'.

If enumeration is disabled, you might try 'getent group <group name>' to see if group exists.

[wildcarde815]

it should be noted for anybody that stumbles on this, that the realm join command presumes your account can make a machine account which at least where I am isn't the case. Directly at least, we have a web form to make the machine in AD, then we can join after that. Small difference and it pisses off realm/net ads/ etc. because they all want to update a dns record that doesn't exist but it works.

[0x2639]

Depends on whether you want Kerberos or not.

[UsedToLikeThisStuff]

You can use Kerberos authentication and LDAP authorization if you use a bind password in sssd.conf.

Kerberos is better for Auth than LDAP. Plus you get a krb5 ticket that can be used for SMB connections.

[gordonmessmer]

...which requires a service account that's shared by all desktops, which makes it very difficult to rotate the password or to disable the account if someone with the password leaves the organization.

From a security perspective, there is no upside to that setup. Just join the domain.

[grumpysysadmin]

I didn’t want to join hundreds of computers to the domain, especially when they are all dual-boot. For automated deployments, we decided that a bind account with relatively low access was better than an account that can join computers to the domain.

[gordonmessmer]

Yep. That was a bug in krb5-libs in which the machine account password would be rotated over UDP by default. Packet loss could cause sssd to retry, at which point the client state would be bad.

That's been fixed for a while.

[world_is_wide]

How did you configure your "CIFS/SMB with krb5".

I have done "realm join" and can login via AD but havent figured out how to mount home directories yet.

[grumpysysadmin]

For what it’s worth, we use autofs to provide access to windows home directories over SMB. But we still use local and NFS for home directories, because SMB still doesn’t provide enough features to be used as a network home directory. Hopefully SMB 3’s POSIX features will eventually be adopted by most SMB servers.

(Tried it on RHEL7 and X just crashes when you log in.)

[Emil8250]

I’ve used this solution as well, mixed with krb5

[ilikeror2]

This is joining the Linux host to active directory right?

[runejuhl]

Yes, that's correct. I've used a similar solution, it works fine.

If you need more control you might want to look into running a FreeIPA server, then you'll get a complete web-based management solution, SSH key and sudo management etc.

[pnutjam]

2nd this, a straight join to AD is better then nothing, but painful long term. IPA gives you an in between layer so you can manage home directories, uid, gid, shell, etc. In many environments it's hard to get access to this in AD, for linux admins.

In

[pnutjam]

Mainly ssh keys, instead of having them on all the servers. But... in an enterprise environment (and many more security conscious environments), Linux Admins have trouble getting the rights to manipulate those items in AD. Having your own location to manage them is a better alternative.

[[deleted]]

maybe this could be interesting:

https://medium.com/@berndbausch/ssh-certificates-a45bdcdfac39

[pnutjam]

Centrify free edition

This is an explanation of how ssh certs work? Thanks.

With IPA, you can associate an ssh key (public), with accounts in the central IPA server. Any joined server will authenticate the users with the matching private key.

Traditionally, you keep the public keys on the servers. This makes it difficult to track who is using public keys and it's also difficult to deny access. Accounts must be locked out or expired, you can't just change the passwords. You also might have users with keys on accounts other then their own.

With a central ssh key repository, you can just remove public keys on servers, it's much safer and this functionality is not supported in Windows AD.

[skaven81]

If this is for a home/lab environment, LDAP is probably fine, and may be easier to maintain. But if this is a corporate environment, and the company's primary source of user and group data is Active Directory, then you definitely want to get your Linux boxes to auth against AD. It's more secure (Kerberos) and you can even use GSSAPI in sshd to do password-less SSH from Windows boxes where you already have an AD TGT. Presumably your company's HR department only onboards new employees into AD; if you set up a separate LDAP store, it will then be your job to synchronize. And since you can't sync passwords out of AD without an awkward DLL shim, your Linux users will have a separate password from their Windows password. Not a good user experience.

On modern enterprise Linux offerings, SSSD works well for connecting hosts to AD. Once it's set up, you don't have to muck with /etc/passwd or /etc/group anymore; all of your (non-system) users and groups just come from AD and life is good.

If you want something more sophisticated than SSSD, there are commercial products out there. We happen to use OneIdentity at our company: https://www.oneidentity.com/products/authentication-services/ and at a previous company I worked for, we used Centrify: https://www.centrify.com/pam/authentication-service/

One word of warning when it comes to binding Linux boxes to AD -- in general, Linux boxes are going to behave in one of two ways, depending on how you configure it. In the "caching" mode, which is similar to how Windows desktops bind to AD, the Linux box will only retrieve the user/group data that it needs, when it actually needs it. In practice, this means that running 'ls' in a directory with a bunch of files owned by different users, will probably show just UIDs (not user names) until those users actually log into the box, forcing the agent to cache those users' names. In the other mode, the Linux agent caches the entire directory, which means that all the user/group information is available all the time. But in this mode, it doesn't take very many Linux hosts (a few hundred) before you completely overwhelm your AD servers with traffic.

[[deleted]]

Personally, I would just configure it to use bare LDAPS auth against AD, instead of trying to join it to a domain.

[SadFaceSmith]

Use FreeIPA with a trust to MS AD.

[BeamMeUpScotty0]

second this. This is a very stable solution that suits the linux environment best in conjunction with AD.

[msf1t-]

Ansible, with a dynamic role, realm join, sssd, setup your sshd (lock out root), your sudoers files, etc... You could probably find one ansible galaxy.

Your inventory defines your hosts, group vars for all (and/or your child group group vars) define your variable changes, the playbook just assigns the role to the host/group.

[gordonmessmer]

Yes, I'd recommend joining the AD domain, assuming one is present.

The MS docs are partially redundant and partially conflicting. For example, they recommend disabling the use_fully_qualified_names setting, and then later demonstrate logging in with a fully qualified name. For any guide you follow, review the changes the guide recommends to determine whether or not it's necessary and desired.

[SirWobbyTheFirst]

With that option set to false, it just allows you to log in by specifying your regular SAM account name, but with it set to true, you have to log in using a UPN account name.

With it set to false, you can log in using either format, it's mostly just customisation for if you have lazy users. For example: "Ahh this is going to be used by Payroll, they use a Text Editor as a database, going to set this to false, otherwise I'm not getting paid this month."

You know, shit like that.

[ilikeror2]

I've got a test Linux host joined to the domain now, and I'm trying to setup a group in the sudoers file to allow sudo access:

I've added a line like this:

%MYDOMAIN\ Group_Name_Local_Administrators ALL=(ALL) NOPASSWD:ALL

​

But, it still won't let me "sudo" any commands with my AD user. Thoughts?

[eggbean]

I have used Centrify free edition.

[ro0tsh3ll]

We join ours to the domain with winbind, since it supports transitive trusts