Translated with DeepL.com

FAQ - KIT-Active Directory

I am an ITB and I would like to use the KIT-AD. What do I have to do?
We recommend that you have your own admin account created for the administration of KIT-AD, see https://www.scc.kit.edu/dienste/8253.php.

Then contact the SCC staff responsible for KIT-AD, specifying your OU and admin account, so that the admin account can be given the necessary rights via membership in <OE>-Admins.
How can I manage the KIT-AD?
First, you can use the Windows Remote Desktop Services provided by the SCC.
If you want to administer from your local PC, you will need Microsoft's Remote Server Administration Tools (RSAT). You can get them from the Microsoft Download Center.
Where can I find more information about KIT-AD?
I am not an ITB, but would like to use KIT-AD as well. Do I get my own area?
Project groups that cannot be assigned to an OU can be given their own area after consultation. However, the following restrictions apply to such an area:
  • IDM objects cannot be moved to this area.
  • The IDM cannot provision objects into this area, therefore e.g. the group management (GV) cannot be used.
What must my computers, user accounts, etc. be called in KIT-AD?
KIT-AD is used by all organizational units of KIT. Since the object names in Active Directory are flat, it must be organizationally ensured that no name similarities occur. Therefore, the names of all AD objects must always start with the OU abbreviation.
What am I allowed to do in KIT-AD?
Basically, you can use the AD as you were used to. You can create and manage users, groups, computers or group policies.

But now the KIT-AD is not authoritative for personal user accounts and groups. These objects are provisioned from the central KIT-IDM system into the KIT-AD. Therefore, these objects must not be deleted in KIT-AD!

Furthermore, it is important that an overlap-free namespace is available to all objects created in KIT-AD. Therefore, each object must start with the OU abbreviation. Individual solutions must be found for facilities with long OU abbreviations.
What am I explicitly not allowed to do in KIT-AD?
You are not allowed to delete any users or groups managed by the IDM!
  • All objects created by you must necessarily start with your OU abbreviation, e.g. SCC employee.
With the right to move these objects, you automatically also have the right to delete, but you may not use this right.
How do I access the KIT-AD via LDAP?
The KIT-AD can be addressed via LDAP as follows:
  • Computer name: kit-ad.scc.kit.edu
  • Port: 636
  • Protocol: LDAP SSL
The configuration for mail clients like Thunderbird is available under
https://www.scc.kit.edu/dienste/8318.php
documented.
What local settings are needed to increase network security?
Windows clients that are not integrated into the central kit.edu domain but use AD for authentication must be adjusted after LDAP signing is switched on.
This can be done either by setting a registry key:
Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap the value ldapclientintegrity is set (type: REG_DWORD - data or value: 2).
Alternatively, this can be set through the Local Computer Policies:
Computer Configuration - Windows Settings - Security Settings - Local Policies - Security Options.
Policy: "Network security: Signature requirement for LDAP clients".
Value: "Signature required".
My computers are in AD with the wrong FQDNs.
By default, when a machine joins the domain, it gets a PrimaryDNSSuffix that corresponds to the AD domain name. So, in our case, kit.edu. So the machine's FQDN published in AD would be <hostname>.kit.edu.

However, this is incorrect and generally does not correspond to the machine's FQDN published in DNS. This is usually <hostname>.<oe>.kit.edu. This mismatch between AD domain name and machine domain name is called a "disjoint namespace".

Therefore, the correct procedure would be to enter the Primary DNS Suffix correctly in the Advanced System Settings on the clients before joining the domain and not have it changed when domain membership is changed. However, this does not work reliably with Windows 7. Instead, you get the error message "Error changing the DNS name for this computer's primary domain...".

Therefore, we generally recommend setting the Primary DNS suffix via a Group Policy (GPO).

As a template for your own GPO, you can use the SCC's GPO named "SCC-DNS-SetPrimaryDNSSuffix_scc.kit.edu".

For this GPO to work, the client must be authorized to change the ServicePrincipalName (SPN) of its own computer object. By default, a client cannot do this. To do this, you must contact the SCC staff responsible for KIT-AD, who can use the Active Directory attribute "msDS-AllowedDNSSuffixes" to control the DNS suffixes allowed for SPNs.

Note that in the case of a GPO, the clients' advanced system settings will still show the old values. However, this is only a cosmetic issue and does not affect the function.

Furthermore, the GPO often only takes effect after the second reboot. You can check the success either in the properties of the computer object in AD or at the client using ipconfig /all.
Is there a WINS server?
No.
Do I get my own DC?
A RODC is only available in well-founded exceptional cases.
Am I allowed to publish printers in KIT-AD?
Yes.
Am I allowed to manage group policies?
Yes.
Can I publish my own DHCP server in AD?
Only after consultation with us. The SCC also offers a DHCP service and in most cases it is not necessary to operate an institute's own DHCP service.
Is there a DFS server?
No.
How can I control who is allowed to log on to my computers?
By default, the local users group includes the following groups, which thus also have the possibility of local login:
  • KIT\Domain Users
  • NT AUTHORITY\Authenticated Users
  • NT AUTHORITY\INTERACTIVE

Via group policies you now have at least two options:
  • Restrict the "Login" right (GPO: Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / User Rights Assignment / Allow log on locally)
  • Explicitly regulate the membership of local user and administrator groups (GPO: Computer Configuration / Policies / Windows Settings / Security Settings / Restricted Groups)

If you don't want every KIT user to be allowed to log in, the groups "KIT\Domain Users" and "NT AUTHORITY\Authenticated Users" must not be included anymore.
How do I add a computer to the AD?

Some time ago, Microsoft released a patch for the DCs, the effects of which we are only now noticing.

A computer account that is already in use must now first be deleted and then recreated (see below).

The computer account must be recreated and the computer added using the same administrator account.

If you now want to add a computer to the AD, you must proceed as follows:

  • In AD, please go to the OU in which the computer account is to be created.
  • Then first create a new computer account here
  • Make sure that your admin group <OE>-Admins is specified in the lower part - it always automatically says "Domain Admins".
  • Only now do you go to the computer and add it to the domain.
Why am I not allowed to change some groups in KIT-AD?
You can only change groups that you have explicitly created in KIT-AD.

Groups (so-called GV-groups or central groups), which were created via the group management (GV), have an access restriction in KIT-AD. This is to prevent properties of the group from changing without the knowledge of the GV. The GV is authoritative for the central groups. Changes (this includes deletion) to Central Groups may only be made via the GM.
Which properties of IDM accounts are read-only in KIT-AD?
IDM accounts (this includes all user accounts authoritatively managed by the IDM system, e.g. employee accounts, guest-and-partner accounts, service accounts, admin accounts, etc.) are write-protected for the following LDAP attributes:

"department", "description", "displayName", "gidNumber", "givenName",
"mail", "sAMAccountName", "sn", "uidNumber", "userPrincipalName",
"physicalDeliveryOfficeName", "telephoneNumber",
"extensionAttribute1", "extensionAttribute2", "extensionAttribute3",
"extensionAttribute4", "extensionAttribute5", "extensionAttribute6",
"extensionAttribute7", "extensionAttribute8", "extensionAttribute9",
"extensionAttribute10", "extensionAttribute11", "extensionAttribute12",
"extensionAttribute13, extensionAttribute14, extensionAttribute15.

Furthermore, the following security settings are given a DENY right:

"user-account-restrictions", "WriteDacl", "WriteOwner".
"User-Force-Change-Password", "User-Change-Password".
Which properties of GV-Groups are read-only in KIT-AD?
GV-Groups get the following write protection:

"description", "gidNumber", "member", "mail", "sAMAccountName",
"extensionAttribute1", "extensionAttribute2", "extensionAttribute3",
"extensionAttribute4", "extensionAttribute5", "extensionAttribute6",
"extensionAttribute7", "extensionAttribute8", "extensionAttribute9",
"extensionAttribute10", "extensionAttribute11", "extensionAttribute12",
"extensionAttribute13, extensionAttribute14, extensionAttribute15.

Furthermore, the following security settings are given a DENY right:

"WriteDacl", "WriteOwner".

 

How do I move an AD object to another OU?
If you don't have write permissions in the target OU, move the object to the OU=Checkpoint Charlie, DC=KIT, DC=EDU.

There every OU admin has write and read permissions. So the OU admin of the recipient OU can move the object from Checkpoint Charlie to his own OU after consulting with you.
How can I set a default user profile for my users?
 
There is a place in the registry to define where the Default User Profile is taken from:
  • HKLM / Software / Microsoft / Windows NT / Current Version / ProfileList

The entry "Default" can be set to a UNC path, e.g. to \AUTHORITY\Authenticated Users.

This registry setting in turn can be distributed via GPO:
  • Computer Configuration / Preferences / Windows Settings / Registry
Connection of desktop systems based on Unix/Linux to the KIT environment
Preface
This manual was created as an example for Debian/Ubuntu. In principle, however, it should also work for other distributions.
Especially OpenLDAP libraries and MIT Kerberos are used. For different environments (e.g. Heimdal-Kerberos) major adaptations may be necessary.
It is not necessary in this approach to include desktop systems in the KIT environment.
It is possible to connect purely with LDAP and do without Kerberos, but Kerberos connection is recommended, e.g., for easier access to central file shares later via the CIFS protocol.
This configuration relies on NSS-LDAP and PAM-KRB5 as the lowest common denominator. However, more current approaches such as SSSD should also be considered and may offer advantages such as offline caching when used on a notebook.
Software installation:
Under Debian/Ubuntu, the necessary packages are installed as follows.
"aptitude install libnss-ldap libpam-krb5 krb5-user ntp nscd".
Name resolution
The file name resolution is usually configured via the file "/etc/resolv.conf", currently e.g. as follows:
search oe.kit.edu kit.edu
nameserver 141.52.8.18
nameserver 141.52.3.3
Kerberos configuration
Configuration files:
/etc/krb5.conf
[libdefaults]
default_realm = KIT.EDU
#krb4_config = /etc/krb.conf
#krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forward = true
forwardable = true
proxiable = true
# Current systems use secure mechanisms based on e.g. AES and SHA
# Under certain circumstances, operating systems may still be in use that do not support AES/SHA.
# In these cases, the use of weak encryption may have to be explicitly permitted.
# However, it makes sense to update/upgrade the operating systems in use.
#allow_weak_crypto = 1
#default_tgs_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
#default_tkt_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
#preferred_enctypes = RC4-HMAC DES-CBC-MD5 DES-CBC-CRC
#[realms]
# KIT.EDU = {
 
# kdc = kit-dc-15.kit.edu:88
 
# admin_server = kit-dc-15.kit.edu:749
 
# kpasswd_server = kit-dc-15.kit.edu:464
 
# default_domain = kit.edu
 
# }
[logging]
default = SYSLOG:INFO:DAEMON
Test
>> kdestroy
>> klist
Shows the error message "klist: No credentials cache found" or similar.
>> kinit ab1234
Queries the password for the account "ab1234" and returns no error message.
>> klist
Now displays information about the existing ticket for"ab1234∂KIT.EDU".
Configuration LDAP
Prerequisite: Proxyuser
To integrate the KIT-LDAP, access via a proxy user is required. For this purpose, a corresponding sample ticket can be created or you can contact patrick.hagen∂kit.edu directly with a signed e-mail. In doing so, you also specify the purpose as well as the scope of the required data so that server-side filtering can be set up if necessary.
Configuration /etc/ldap.conf
uri ldaps://kit-ldap-01.scc.kit.edu kit-ldap-02.scc.kit.edu/
base ou=unix,ou=IDM,dc=kit,dc=edu
ldap_version 3
binddn cn=xxx,ou=ProxyUser,ou=idm,dc=kit,dc=edu
bindpw xxxxxx
nss_base_passwd ou=People,ou=unix,ou=IDM,dc=kit,dc=edu?sub?uidnumber=*
nss_base_shadow ou=People,ou=unix,ou=IDM,dc=kit,dc=edu?sub?uidnumber=*
nss_base_group ou=Groups,ou=unix,ou=IDM,dc=kit,dc=edu nss_map_attribute
gecos displayName
ssl yes
 
Test
>> ldapsearch -x "(uid=ab1234)"
Returns information about the account "ab1234".
Securing /etc/ldap.conf
The configuration file contains the credentials that the proxy user can use to access the LDAP service and therefore must be appropriately protected. By default, however, this file is set up as "Readable by all users" because each user must resolve accounts and groups.
However, the file permissions can be restricted to "readable for root" if you also install the "nscd" service which runs with root permissions.
Resolving Unix accounts or setting up NSS
Configuration /etc/nsswitch.conf
passwd: compat ldap
group: compat ldap
shadow: compat ldap
 
tests:
>> getent passwd ab1234
this should return a valid entry for user "ab1234
>> getent group OE-Users-IDM
output of the group "OE-Users-IDM
Setup authentication or PAM
This configuration is complex and error-prone. In particular, errors can result in logins without a password or with an invalid password. Therefore thorough tests are necessary and the configuration should not be done directly if possible, but via tools provided by the distributions. Under Debian/Ubuntu, for example, via pam-auth-update
 
 
Status: 2014-03-27
Based on a tutorial by: Jürgen Engelmann