18.04 AD integration: Limit which users are able to log in?

[scottws]

I am following Ubuntu's guide for AD integration of Ubuntu 18.04 (https://help.ubuntu.com/lts/serverguide/sssd-ad.html), but I want to limit what domain users can log into the system based on AD group membership. I would also like to be able to allow AD users to use sudo (again, based on AD group membership and possibly a subset of AD users that can log in at all).

Where can I find documentation on how to accomplish this?

For reference, here are my relevant config files:

/etc/krb5.conf:

[libdefaults]
default_realm = DOMAIN.COM
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
fcc-mit-ticketflags = true
ticket_lifetime = 24h #
renew_lifetime = 7d

[realms]
DOMAIN.COM = {
kdc = server1.domain.com
kdc = server2.domain.com
kdc = server3.domain.com
kdc = server4.domain.com
kdc = server5.domain.com
kdc = server6.domain.com
kdc = server7.domain.com
kdc = server8.domain.com
kdc = server9.domain.com
admin_server = server1.domain.com
default_domain = DOMAIN.COM
}

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

/etc/samba/smb.conf:

[global]
workgroup = DOMAIN
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = DOMAIN.COM
security = ads
server string = %h server (Samba, Ubuntu)
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
server role = standalone server
passdb backend = tdbsam
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = no

/etc/sssd/sssd.conf:

[sssd]
services = nss, pam
config_file_version = 2
domains = DOMAIN.COM

[domain/DOMAIN.COM]
id_provider = ad
access_provider = ad

# Use this if users are being logged in at /.
# This example specifies /home/DOMAIN-FQDN/user as /home/svclinux. Use with pam_mkhomedir.so
override_homedir = /home/%d/%u

# Uncomment if the client machine hostname doesn't match the computer object on the DC.
# ad_hostname = hostname.domain.com

# Uncomment if DNS SRV resolution is not working
# ad_server = server1.domain.com

# Uncomment if the AD domain is named differently than the Samba domain
# ad_domain = DOMAIN.COM

# Enumeration is discouraged for performance reasons.
# enumerate = true

[TheFu]

I know ZERO about AD. Successfully have avoided it for the last 12 yrs!

However, for any userid to have the ability to use sudo, there are multiple ways to configure the sudoers et al configuration files. The short answer is don't put anyone into the sudo POSIX group unless you want them to be able to use sudo. There are many, many, other non-admin reasons to use sudo, but I'm guessing none of those are your concern today. You can check the group membership for your account using the 'id' command.
You can get a list of members in the sudo group using getent group sudo. This works with both file-based user/group management and with standard LDAP, so it should work with a correctly integrated AD setup.

[scottws]

I was able to determine the answer for limiting which users are able to log into the system. There is an ad_access_filter directive available when using access_provider=ad in /etc/sssd/sssd.conf which uses LDAP search filter syntax. For example:

[domain/EXAMPLE.COM]
id_provider = ad
access_provider = ad
ad_access_filter = (memberOf=CN=Domain Admins,DN=Users,DC=example,DC=com)

Next is to figure out what needs to go in /etc/sudoers so that some of the AD users are able to use sudo to administer the system.

[TheFu]

"An answer" is not the same as "the answer".
On Unix systems, there is usually 50 - 500 different solutions to any problem.
sudoers supports using groups, so create an AD POSIX group, put all the Linux admins you like inside it, then add that to a file in /etc/sudoers.d/ following the README there. The filename needs to match the required pattern. If you have more than 5 systems to be managed this way, using ansible is how I'd deploy the specific settings after testing them out on one first. If the sudoers gets messed up, the only solution might be to boot from a flash "try ubuntu" disk, remove the problem file and start over.

[scottws]

Yes, of course that's true. There are also simple and ldap access providers in addition to the ad access provider, and each has their own pluses and minuses and syntax.

Regarding sudoers, my question was about the exact syntax to match an AD group using the SSSD method of AD integration. I'd used pbis-open for AD integration previously, and know how it is done for that. After testing, the syntax is:

%Domain\ Admins ALL=(ALL) ALL

As you stated, I put that (as well as other internal groups deemed necessary) in a file /etc/sudoers.d/EXAMPLE with 0440 permissions, and this works. In contrast to some other comments I found in my research, it's not necessary to indicate the domain name as part of the group (in fact it does not work if you specify it).