Please note the following requirements when joining to DIT’s Active Directory service.
General information about DIT’s Active Directory service can be found here in ServiceNow:
https://itsupport.umd.edu/itsupport?id=kb_article_view&sysparm_article=KB0012415
Before you can join a host to AD, you must have an organizational unit (OU) assigned to your department and be granted the appropriate permissions to that OU.
If you do not already have an OU assigned to you, please reach out to the AD team to discuss your use case. The AD team can be contacted at UMD-AD@umd.edu.
Once you have met with the AD team, you can fill out and submit the “OU (Organizational Unit) Administrator Access” request form:
https://itsupport.umd.edu/itsupport?id=sc_cat_item&sys_id=24cbdc866fb83e405cdc1cccbb3ee4f7
Be sure to read and understand all reference material linked in the above form:
Once approved, the AD team will create your OU and delegate administrative access to it as needed.
If you already have an OU assigned to your unit, all administrators with the appropriate permissions can join hosts to the domain.
Use the “OU (Organizational Unit) Administrator Access” form above in the ”Need an OU Created?” section to request access for other administrators within your unit if needed. Again, be sure all administrators read and understand the reference material linked in the request form.
Red Hat and Ubuntu provide general instructions on joining hosts to Active Directory. For more in-depth information, please see the links below:
The basics instructions have been boiled down below.
Before you start, see this document and confirm the listed ports on the AD server are accessible to your host.
With access confirmed, you may join hosts to the domain:
Once your host is joined to the domain, the following command should now return a value for any AD user account:
getent passwd <DIR_ID>@AD.UMD.EDU
For example:
$ getent passwd cbettenh@AD.UMD.EDU
cbettenh@AD.UMD.EDU:*:866475304:1491000513:cbettenh:/home/cbettenh@AD.UMD.EDU:/bin/bash
Similarly , run "realm list" to list all of the configured domains. You should see output similar to that of "realm discover AD.UMD.EDU" above for the AD.UMD.EDU realm indicating the realm is now configured on this host. Also, the value for the “configured” key in the output should now be “kerberos-member”.
[root@itusunix0001 sssd]# realm list
AD.UMD.EDU
type: kerberos
realm-name: AD.UMD.EDU
domain-name: ad.umd.edu
configured: kerberos-member <--- HERE
[...]
You should also be able to SSH into the host using your AD account credentials:
ssh <DIR_ID>@AD.UMD.EDU@<FQDN>
where <DIR_ID> is your Directory ID, and <FQDN> is the fully-qualified domain name of the host joined to the AD. For example:
cbettenh@laptop ~ % ssh cbettenh@AD.UMD.EDU@itusunix0001.ad.umd.edu
cbettenh@AD.UMD.EDU@itusunix0001.ad.umd.edu's password:
[...]
Last login: Mon Jun 9 10:39:39 2025 from 10.206.37.171
[cbettenh@AD.UMD.EDU@itusunix0001 ~]$
If that all checks out, your host is now confirmed to be bound to DIT’s Active Directory!
Next, please see the “Restricting Access by User or Group” section below!
NOTE: By default, hosts bound to AD will allow any person with an AD account (aka everyone at the university) to log into the host! You must now restrict access. See the “Restricting Access by User or Group” section below to implement access controls.
NOTE: DIT’s Active Directory does not populate the Unix attributes (uidNumber, gidNumber, loginShell, unixHomeDirectory, etc) on user accounts. As a result, ID mapping must be used (ldap_id_mapping = True) on AD clients. For more information on ID mapping, see the “ID Mapping” section on the sssd-ad manual page (man sssd-ad).As a result, UIDs and GIDs created via ID mapping will not match UIDs and GIDs in LDAP or on other DIT-managed Linux hosts.
Out of the box, a host newly jointed to AD will allow access to any AD user. In most cases, this is not the desired state. SSSD allows you to restrict access to a host to specific users or members of a group. See the sections below for instructions.
If you’d like to restrict access to a host to a specific list of users, you can use the "realm permit" command to do so. Collect your list of users and run:
# realm permit -v -R AD.UMD.EDU <DIR_ID>@AD.UMD.EDU <DIR_ID>@AD.UMD.EDU ...
For example:
# realm permit -v -R AD.UMD.EDU cbettenh@AD.UMD.EDU henry@AD.UMD.EDU
* /usr/bin/systemctl restart sssd.service
* Successfully changed permitted logins for realm
In /etc/sssd/sssd.conf, the command above results in the following changes:
# This is changed to 'simple' from 'ad' to activate the simple access controls.
access_provider = simple
# Actual list of users that are allowed access.
simple_allow_users = cbettenh, henry
As noted in the "realm permit" output, the sss daemon is automatically restarted after the changes are made, so manual restarting the daemon is not needed.
The users specified should now be able to log into the host.
Similar to the user section above, if you’d like to restrict access to a host to a specific list of AD groups, you can also use the "realm permit" command to do so. Collect your list of groups and run:
# realm permit -v -R AD.UMD.EDU -g <AD_GROUP1>@AD.UMD.EDU <AD_GROUP2>@AD.UMD.EDU ...
For example:
# realm permit -v -R AD.UMD.EDU -g itserveraaccess-ls@AD.UMD.EDU itunixgrpa-gs@AD.UMD.EDU
* /usr/bin/systemctl restart sssd.service
* Successfully changed permitted logins for realm
Again, similar to the user example, the command above causes the following changes to /etc/sssd/sssd.conf:
# This is changed to 'simple' from 'ad' to activate the simple access controls.
access_provider = simple
# Actual list of groups that are allowed access.
simple_allow_groups = itserveraaccess-ls@AD.UMD.EDU, itunixgrpa-gs@AD.UMD.EDU
Only members of the specified groups are now allows access to this host.
If you’d like to unbind a host from DIT’s Active Directory service, follow the instructions below:
By default, use_fully_qualified_domain_names is enabled in /etc/sssd/sssd.conf. According to the sssd.conf manual page, if use_fully_qualified_names is enabled, “… all requests to this domain must use fully qualified names.” For example, login username must be specified as “<DIR_ID>@AD.UMD.EDU” rather than just “<DIR_ID>”.
In many cases, this is unnecessary if all of your users and resources are in a single domain and you have no local users. In that case, you can disable use_fully_qualified_domain_names:
# Disable use_fully_qualified_domain_names so we don't always have to specify our AD domain.
use_fully_qualified_names = False
# Also remove the domain from home directories for consistency.
fallback_homedir = /home/%u
This then allows users to log in using their directory ID only e.g.:
% ssh cbettenh@itusunix0001.ad.umd.edu
cbettenh@itusunix0001.ad.umd.edu's password:
[...]
Last login: Mon Jun 9 11:39:45 2025 from 10.206.37.171
[cbettenh@itusunix0001 ~]$
Looking up account information can also now be done using the directory ID only e.g.:
# getent passwd cbettenh
cbettenh@AD.UMD.EDU:*:866475304:1491000513:cbettenh:/home/cbettenh:/bin/bash
The fully-qualified name can still be used though if needed:
# getent passwd cbettenh@AD.UMD.EDU
cbettenh@AD.UMD.EDU:*:866475304:1491000513:cbettenh:/home/cbettenh:/bin/bash
Generic troubleshooting guidelines:
Troubleshooting Basics - sssd.io
Add the following value to the “[domain/AD.UMD.EDU]” section of your /etc/sssd/sssd.conf file:
debug = 6
NOTE: Debug values may be in the range of 0 - 9. See the sssd.conf manual page for more options ("man sssd.conf").
Then restart SSSD:
systemctl restart sssd
In RHEL, if you see dyndns errors in the sssd_AD.UMD.EDU.log file like this:
(2025-06-07 16:09:04): [be[AD.UMD.EDU]] [ad_dyndns_sdap_update_done] (0x0040): Dynamic DNS update failed [1432158240]: Dynamic DNS update failed
Be sure you have updated the crypto-policies to include AD-SUPPORT:
update-crypto-policies --set DEFAULT:AD-SUPPORT