LDAP and Kerberos: Domain Services Step by Step

14 min readMay 2, 2024

The concept of “domain” in the context of computer networks usually refers to a group of computers combined into a single managed space. A domain allows you to centrally manage users, resources, and security policies.

Integrating servers into a domain typically means connecting servers to a domain environment managed by a centralized directory service (such as Active Directory in a Windows environment or Lightweight Directory Access Protocol (LDAP) in Linux environment). This provides centralized storage of user and group accounts, as well as centralized user authentication when accessing network resources.

Integration involves two services

Centralized account storage (directory service): This means that account information for users, groups, and other objects is stored in a centralized directory (such as LDAP-compatible). Domain-integrated servers use this directory service to authenticate users and control their access to resources.
Centralized Authentication: This means that users only need to authenticate once when logging into the network, and their credentials are verified by a centralized service (such as Kerberos). This allows users to use the same credentials to access different resources on the network, and also simplifies administration since authentication and authorization occur centrally on the domain server.

In a typical domain environment, a Domain Controller (DC) typically also serves as the DNS server for servicing the domain. This is because DNS (Domain Name System) plays a key role in resolving computer names to IP addresses and vice versa, which is an important part of network functioning.

Thus, integrating servers into a domain allows for unified access to network resources, centralized account management and an increased level of security through centralized authentication and authorization.

Here are simplified configuration steps for setting up LDAP, Kerberos, and DNS services on Ubuntu 24.04 LTS:

Setting up a Name Server

DNS (Domain Name System) servers play a crucial role in managing a corporate network environment by mapping human-readable domain names to their corresponding IP addresses. This allows users to access resources on the network using easy-to-remember domain names rather than having to remember IP addresses.

Setting up and running DNS servers ensures efficient communication between hosts on the network and enhances overall network management. Here’s how you can set up a DNS server on Ubuntu 24.04 LTS:

sudo apt update
sudo apt install bind9 bind9utils

And then we add the option to force the use of the IPv4 address space (add parameter -4 to the end of the OPTIONS value):

$ sudo nano /etc/default/named
OPTIONS="-u bind -4"

$ sudo systemctl restart bind9

Configure the BIND server by editing the main configuration file /etc/bind/named.conf.options. Here you can specify options like forwarders, listen-on addresses, etc.

$ sudo nano /etc/bind/named.conf.options

forwarders {
8.8.8.8;
8.8.4.4;
};

Create a zone configuration file for “domain.org” in the /etc/bind/ directory. Let's name it domain.org.zone.

$ sudo nano /etc/bind/domain.org.zone

$TTL    604800
@       IN      SOA     ns1.domain.org. admin.domain.org. (
                                3         ; Serial
                           604800         ; Refresh
                            86400         ; Retry
                          2419200         ; Expire
                           604800 )       ; Negative Cache TTL
domain.org.     IN      NS      kdc.domain.org.
@       IN      A       10.0.0.252
kdc.domain.org. IN      A       10.0.0.252

Open the BIND configuration file /etc/bind/named.conf.local for editing.

$ sudo nano /etc/bind/named.conf.local

zone "domain.org" {
    type master;
    file "/etc/bind/domain.org.zone";
};

$ sudo systemctl restart bind9

Test DNS resolution using utilities like nslookup or dig from client machines.

> nslookup domain.org
Server:  UnKnown
Address:  10.0.0.252

Name:    domain.org
Address:  10.0.0.252

Configure OpenLDAP

We are going to install the OpenLDAP server on the same host as the Key Distribution Center (KDC), to simplify the communication between them.

Setting up OpenLDAP as an alternative to Active Directory on Ubuntu 24.04 LTS involves several steps, including installation, configuration, and initial setup. You can install the server and the main command line utilities with the following command:

sudo apt update
sudo apt install slapd ldap-utils

During the installation of OpenLDAP, you will be prompted to configure certain settings to customize the setup according to your requirements. Here are the settings you might be asked to set during the installation process:

Administrator Password: You’ll be asked to set an administrator password for the LDAP directory. This password is crucial for administrative tasks such as adding, modifying, or deleting entries in the LDAP directory.

LDAP Organization Name: You may be prompted to enter the organization name for your LDAP directory. This is typically used for informational purposes and can be customized based on your organization’s name.

LDAP Domain Name: You’ll need to specify the domain name for your LDAP directory. This domain name will be used as part of the distinguished names (DNs) for entries in the LDAP directory.

In our example the name domain.org will be used.

If you want to change your Directory Information Tree (DIT) suffix, now would be a good time since changing it discards your existing one. To change the suffix, run the following command:

sudo dpkg-reconfigure slapd

To save some typing, we can configure the OpenLDAP libraries with certain defaults in /etc/ldap/ldap.conf (adjust these entries for your server name and directory suffix):

BASE dc=domain,dc=org
URI ldap://kdc.domain.org

To check the connection to an Apache Directory Server (Apache DS), you can use various methods. Here are a few options:

LDAP Browser/Client Tools: Use LDAP browser or client tools like Apache Directory Studio or ldapsearch command-line tool to connect to the DC server. You’ll need to provide the server address, port, and credentials if authentication is required. Once connected, you can browse the directory tree and perform operations like searching for entries or modifying data.

So, in Apache DS check connection to empty directory:

LDAPSEARCH Command:

ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

ldapsearch -x -LLL -H ldap:/// -b dc=domain,dc=org dn

Check commands:

ldapwhoami -x

ldapwhoami -x -D cn=admin,dc=domain,dc=org -W

These methods should help you verify the connection to your Directory Server and diagnose any connectivity issues.

The rootDSE (Directory Service Entry) is a special entry in LDAP (Lightweight Directory Access Protocol) that represents the root of the directory information tree (DIT) on an LDAP server. It provides a means for clients to obtain information about the capabilities and configuration of the LDAP server itself.

Here are some key points about the rootDSE:

Location: The rootDSE is located at the base DN (Distinguished Name) of the LDAP server, typically represented as an empty string or as the root of the directory tree ("" or "dc=domain,dc=org" in our example).
Attributes: The rootDSE contains various attributes that provide information about the LDAP server, such as supported LDAP versions, supported authentication mechanisms, naming contexts, supported controls, and other configuration details.
Purpose: Clients can query the rootDSE to discover essential information about the LDAP server, such as the supported LDAP protocol versions and authentication mechanisms, which helps them configure their LDAP operations accordingly.
Read-Only: In most cases, the rootDSE is read-only, meaning that clients can query its attributes but cannot modify them. However, some attributes, such as supported controls or supported LDAP versions, may change dynamically based on server configuration.
Examples of Attributes:

namingContexts: Provides a list of naming contexts (base DNs) supported by the server.
supportedLDAPVersion: Indicates the LDAP protocol versions supported by the server.
supportedSASLMechanisms: Lists the SASL (Simple Authentication and Security Layer) mechanisms supported by the server for authentication.

In summary, the rootDSE serves as a starting point for clients to discover essential information about an LDAP server, enabling them to interact with the server more effectively and efficiently.

Since at the beginning the name server was set to use only IPv4, we will tell the directory service to use only this protocol. To do this, in the /etc/default/slapd file we will set SLAPD_OPTIONS=”-4".

In order for us to be able to see directory service events in the system log as a separate file, we will configure rsyslog.
To do this, add the following text to /etc/rsyslog.conf after the $IncludeConfig instruction:

if $programname == 'slapd' then /var/log/slapd.log
& ~

Now let’s create a file for the directory service log and assign access rights to it.

sudo touch /var/log/slapd.log
sudo chmod 0640 /var/log/slapd.log
sudo chown syslog:adm /var/log/slapd.log

sudo systemctl restart rsyslog

Next, we configure the directory service log rotation rules. To do this, create a configuration file /etc/logrotate.d/slapd and add the text to it:

/var/log/slapd.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
}

Let’s check the rotation settings:

sudo logrotate -df /etc/logrotate.conf

sudo systemctl restart slapd

sudo tail /var/log/slapd.log

sudo systemctl enable slapd

Populate the directory

Let’s introduce some content to our directory. We will add the following:

A node called People, to store users
A user called master
A node called Groups, to store groups
A group called internal

Create SSHA password (for example: masterkey) for use in userPassword attribute:

$ slappasswd
New password: 
Re-enter new password: 
{SSHA}LCnLY5n2hKtE2NZWWJqv7qd0K91bOXx2

Create the following LDIF file and call it add_content.ldif:

dn: ou=People,dc=domain,dc=org
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=domain,dc=org
objectClass: organizationalUnit
ou: Groups

dn: cn=internal,ou=Groups,dc=domain,dc=org
objectClass: posixGroup
cn: internal
gidNumber: 5000

dn: uid=master,ou=People,dc=domain,dc=org
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: master
sn: Dubetcky
givenName: Oleh
cn: Oleh Dubetcky
displayName: Oleh Dubetcky
uidNumber: 10000
gidNumber: 5000
userPassword: {SSHA}LCnLY5n2hKtE2NZWWJqv7qd0K91bOXx2
gecos: Oleh Dubetcky
loginShell: /bin/bash
homeDirectory: /home/master

Add the content:

$ ldapadd -x -D cn=admin,dc=domain,dc=org -W -f add_content.ldif 
Enter LDAP Password: 
adding new entry "ou=People,dc=domain,dc=org"

adding new entry "ou=Groups,dc=domain,dc=org"

adding new entry "cn=internal,ou=Groups,dc=domain,dc=org"

adding new entry "uid=master,ou=People,dc=domain,dc=org"

We can check that the information has been correctly added with the ldapsearch utility. For example, let’s search for the “master” entry, and request the cn and gidnumber attributes:

$ ldapsearch -x -LLL -b dc=domain,dc=org '(uid=master)' cn gidNumber
dn: uid=master,ou=People,dc=domain,dc=org
cn: Oleh Dubetcky
gidNumber: 5000

Or in Apache DS:

To change the password to something valid, you can now use ldappasswd:

$ ldappasswd -x -D cn=admin,dc=domain,dc=org -W -S uid=master,ou=people,dc=domain,dc=org
New password: 
Re-enter new password: 
Enter LDAP Password:

Setting up a secure connection (TLS)

Configuring TLS when using OpenLDAP is highly recommended both to support LDAP authentication using the SASL EXTERNAL mechanism and to implement functions of confidentiality and data integrity.
To configure TLS on the server, you will need an SSL certificate and private key. The certificate must be signed by a trusted certification authority (Certificate Authority, CA) or, in test environment, own certification authority.

Generate a Private Key: You can generate a private key using OpenSSL (Replace kdc.domain.org = Your-FQDN), Generate a Certificate Signing Request (CSR) and Sign certificate:

openssl genrsa -aes128 -out kdc.domain.org.key 4096

openssl rsa -in kdc.domain.org.key -out kdc.domain.org.key

openssl req -new -days 3650 -key kdc.domain.org.key -out kdc.domain.org.csr 

sudo openssl x509 -in kdc.domain.org.csr -out kdc.domain.org.crt -req -signkey kdc.domain.org.key -days 3650

Move the generated certificate and key to a directory accessible by OpenLDAP:

sudo mv kdc.domain.org.crt /etc/ldap/sasl2/
sudo mv kdc.domain.org.key /etc/ldap/sasl2/

cp /etc/ssl/certs/ca-certificates.crt /etc/ldap/sasl2/

sudo chown -R openldap:openldap /etc/ldap/sasl2/

Update LDAP Configuration, create LDAP configuration file ssl.ldif and apply:

$ nano ssl.ldif

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/sasl2/ca-certificates.crt
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/sasl2/kdc.domain.org.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/sasl2/kdc.domain.org.key

$ sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"

Edit /etc/default/slapd file and add ldaps:/// to SLAPD_SERVICES

$ nano /etc/default/slapd

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Edit /etc/ldao/ldap.conf file and add TLS_CACERT and TLS_REQCERT

#TLS_CACERT     /etc/ssl/certs/ca-certificates.crt
TLS_CACERT /etc/ldap/sasl2/ca-certificates.crt
TLS_REQCERT allow

Now, restart LDAP service to apply the changes

sudo systemctl restart slapd

Verify be ldapsearch command:

ldapsearch -x -H ldaps://kdc.domain.org -b "dc=domain,dc=org"

netstat -antup | grep -i 636

The Secure LDAP server is listening on port 636. We need to open port 636 to allow LDAP clients to communicate with the LDAP server if use Firewall.

On LDAP Client

TLS_REQCERT allow

Verify be ldapsearch command:

ldapsearch -x -H ldaps://kdc.domain.org -b "dc=domain,dc=org"

Testing with Python

You can use this Python code for instance, make sure you install the ldap3 library, replace the values according to your setup of course:

from ldap3 import Server, Connection, ALL, SUBTREE , Tls
import ssl

# SSL/TLS configuration
tls = Tls(validate=ssl.CERT_NONE, version=ssl.PROTOCOL_TLSv1_2)
# Create LDAP server object
server = Server('ldaps://domain.org', use_ssl=True, tls=tls, get_info=ALL)
# Create LDAP connection object
conn = Connection(server, user='cn=admin,dc=domain,dc=org', password='Masterkey',auto_bind=True)

if not conn.bind():
    print('Failed to bind to LDAPS server:', conn.result)
else:
    print('Successfully connected to LDAP server')

base_dn = 'dc=domain,dc=org' 

search_filter = '(&(objectClass=person)(cn=*))'

# Perform the search
conn.search(search_base=base_dn,
            search_filter=search_filter,
            search_scope=SUBTREE,
            attributes=['cn', 'mail'])  # Add more attributes as needed

# Iterate over the search results
for entry in conn.entries:
    print('DN:', entry.entry_dn)
    print('Common Name (CN):', entry.cn)
    if 'mail' in entry:
        print('Email:', entry.mail)

# Unbind from the server
conn.unbind()

#Successfully connected to LDAPS server
#DN: uid=master,ou=People,dc=domain,dc=org
#Common Name (CN): Oleh Dubetcky
#Email: []

Configuring Kerberos with LDAP

Now that OpenLDAP is configured, you can begin configuring the Kerberos server. This section will describe how to deploy a Kerberos Key Distribution Center (KDC) for the DOMAIN.ORG realm.

Install the necessary packages:

sudo apt install krb5-pkinit krb5-kdc-ldap krb5-admin-server libsasl2-modules-gssapi-mit

Next, extract the kerberos.schema.gz file:

cp /usr/share/doc/krb5-kdc-ldap/kerberos.schema.gz /etc/ldap/schema/                                             
 
gunzip /etc/ldap/schema/kerberos.schema.gz

The Kerberos schema needs to be added to the cn=config tree. This schema file needs to be converted to LDIF format before it can be added. For that we will use a helper tool, called schema2ldif, provided by the package of the same name which is available in the Universe archive:

sudo apt install schema2ldif

To import the Kerberos schema, run:

$ sudo ldap-schema-manager -i kerberos.schema

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
executing 'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/kerberos.ldif'
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=kerberos,cn=schema,cn=config"

To check that the schema is installed, run:

$ sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn | grep -i kerberos

dn: cn={4}kerberos,cn=schema,cn=config

It contains many objects. To see them all, use the following command:

sudo ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn={4}kerberos,cn=schema,cn=config | grep NAME | cut -d' ' -f5 | sort

Let’s create LDAP entries for the Kerberos administrative entities that will contact the OpenLDAP server to perform operations. There are two:

ldap_kdc_dn: needs to have read rights on the realm container, principal container and realm sub-trees. If disable_last_success and disable_lockout are not set, however, then ldap_kdc_dn needs write access to the Kerberos container just like the admin DN below.
ldap_kadmind_dn: needs to have read and write rights on the realm container, principal container and realm sub-trees

Here is the command to create these entities:

$ ldapadd -x -D cn=admin,dc=domain,dc=org -W <<EOF
dn: uid=kdc-service,dc=domain,dc=org
uid: kdc-service
objectClass: account
objectClass: simpleSecurityObject
userPassword: {CRYPT}x
description: Account used for the Kerberos KDC

dn: uid=kadmin-service,dc=domain,dc=org
uid: kadmin-service
objectClass: account
objectClass: simpleSecurityObject
userPassword: {CRYPT}x
description: Account used for the Kerberos Admin server
EOF

Enter LDAP Password: 
adding new entry "uid=kdc-service,dc=domain,dc=org"

adding new entry "uid=kadmin-service,dc=domain,dc=org"

Now let’s set a password for them. Note that first the tool asks for the password you want for the specified user DN, and then for the password of the cn=admin DN:

$ ldappasswd -x -D cn=admin,dc=domain,dc=org -W -S uid=kdc-service,dc=domain,dc=org
New password: 
Re-enter new password: 
Enter LDAP Password:

Repeat for the uid=kadmin-service dn.

$ ldappasswd -x -D cn=admin,dc=domain,dc=org -W -S uid=kadmin-service,dc=domain,dc=org
New password: 
Re-enter new password: 
Enter LDAP Password:

These passwords will be needed later.

You can test these with ldapwhoami:

$ ldapwhoami -x -D uid=kdc-service,dc=domain,dc=org -W
Enter LDAP Password: 
dn:uid=kdc-service,dc=domain,dc=org

Finally, update the Access Control Lists (ACL). These can be tricky, as it highly depends on what you have defined already. By default, the slapd package configures your database with the following ACLs:

olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read

We need to insert new rules before the final to * by * read one, to control access to the Kerberos related entries and attributes:

$ ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF

dn: olcDatabase={1}mdb,cn=config
add: olcAccess
olcAccess: {2}to attrs=krbPrincipalKey
  by anonymous auth
  by dn.exact="uid=kdc-service,dc=domain,dc=org" read
  by dn.exact="uid=kadmin-service,dc=domain,dc=org" write
  by self write
  by * none
-
add: olcAccess
olcAccess: {3}to dn.subtree="cn=kerberos,dc=domain,dc=org"
  by dn.exact="uid=kdc-service,dc=domain,dc=org" read
  by dn.exact="uid=kadmin-service,dc=domain,dc=org" write
  by * none
EOF

modifying entry "olcDatabase={1}mdb,cn=config"

Your LDAP directory is now ready to serve as a Kerberos principal database.

Primary KDC configuration (LDAP)

With OpenLDAP configured it is time to configure the KDC. In this example we are doing it in the same OpenLDAP server to take advantage of local UNIX socket communication.

Reconfigure the krb5-config package if needed to get a good starting point with /etc/krb5.conf:

sudo dpkg-reconfigure krb5-config

Now edit /etc/krb5.conf adding the database_module option to the DOMAIN.ORG realm section:

[realms]
        DOMAIN.ORG = {
                kdc = kdc.domain.org
                admin_server = kdc.domain.org
                default_domain = domain.org
                database_module = openldap_ldapconf

        }

[domain_realm]
        domain.org = DOMAIN.ORG
        .domain.org = DOMAIN.ORG

[dbdefaults]
        ldap_kerberos_container_dn = cn=kerberos,dc=domain,dc=org

[dbmodules]
        openldap_ldapconf = {
                db_library = kldap

                                # if either of these is false, then the ldap_kdc_dn needs to
                                # have write access
                                disable_last_success = true
                                disable_lockout  = true

                # this object needs to have read rights on
                # the realm container, principal container and realm sub-trees
                ldap_kdc_dn = "uid=kdc-service,dc=domain,dc=org"

                # this object needs to have read and write rights on
                # the realm container, principal container and realm sub-trees
                ldap_kadmind_dn = "uid=kadmin-service,dc=domain,dc=org"

                ldap_service_password_file = /etc/krb5kdc/service.keyfile
                ldap_servers = ldapi:///
                ldap_conns_per_server = 5
        }

Next, use the kdb5_ldap_util utility to create the realm:

$ kdb5_ldap_util -D cn=admin,dc=domain,dc=org create -subtrees dc=domain,dc=org -r DOMAIN.ORG -s -H ldapi:/// 
Password for "cn=admin,dc=domain,dc=org": 
Initializing database for realm 'DOMAIN.ORG'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: 
Re-enter KDC database master key to verify:

Create a stash of the password used to bind to the LDAP server. Run it once for each ldap_kdc_dn and ldap_kadmin_dn:

$ sudo kdb5_ldap_util -D cn=admin,dc=domain,dc=org stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kdc-service,dc=domain,dc=org
Password for "cn=admin,dc=domain,dc=org": 
Password for "uid=kdc-service,dc=domain,dc=org": 
Re-enter password for "uid=kdc-service,dc=domain,dc=org": 

$ sudo kdb5_ldap_util -D cn=admin,dc=domain,dc=org stashsrvpw -f /etc/krb5kdc/service.keyfile uid=kadmin-service,dc=domain,dc=org
Password for "cn=admin,dc=domain,dc=org": 
Password for "uid=kadmin-service,dc=domain,dc=org": 
Re-enter password for "uid=kadmin-service,dc=domain,dc=org":

Create a /etc/krb5kdc/kadm5.acl file for the admin server, if you haven’t already:

*/admin@DOMAIN.ORG        *

Start the Kerberos KDC and admin server:

sudo systemctl start krb5-kdc.service krb5-admin-server.service

You can now add Kerberos principals to the LDAP database, and they will be copied to any other LDAP servers configured for replication. Next, create a host principal for the current server using the kadmin.local utility enter:

$ kadmin.local
Authenticating as principal root/admin@DOMAIN.ORG with password.
kadmin.local:  addprinc -randkey host/kdc.domain.org@DOMAIN.ORG

No policy specified for host/kdc.domain.org@DOMAIN.ORG; defaulting to no policy
Principal "host/kdc.domain.org@DOMAIN.ORG" created.

After creating the server principal, we can add it to the Kerberos keytab (/etc/krb5.keytab):

$ kadmin.local:  ktadd host/kdc.domain.org

Entry for principal host/kdc.domain.org@DOMAIN.ORG with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kdc.domain.org@DOMAIN.ORG with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

The next step is to create a principal for the guest user and set a password for it:

$ kadmin.local:  addprinc guest
No policy specified for guest@DOMAIN.ORG; defaulting to no policy
Enter password for principal "guest@DOMAIN.ORG": 
Re-enter password for principal "guest@DOMAIN.ORG": 
Principal "guest@DOMAIN.ORG" created.

Now let’s create a user principal with administrator rights. Through the /etc/krb5kdc/kadm5.acl file, users with the /admin prefix have administrative rights to access the Kerberos realm. This means they can create and delete user entries and access policies.

$ kadmin.local:  addprinc master/admin
No policy specified for master/admin@DOMAIN.ORG; defaulting to no policy
Enter password for principal "master/admin@DOMAIN.ORG": 
Re-enter password for principal "master/admin@DOMAIN.ORG": 
Principal "master/admin@DOMAIN.ORG" created.

Let’s check the list of current principals in the DOMAIN.ORG realm:

$ kadmin.local:  get_principals
K/M@DOMAIN.ORG
krbtgt/DOMAIN.ORG@DOMAIN.ORG
kadmin/admin@DOMAIN.ORG
kadmin/changepw@DOMAIN.ORG
kadmin/history@DOMAIN.ORG
host/kdc.domain.org@DOMAIN.ORG
guest@DOMAIN.ORG
master/admin@DOMAIN.ORG

Using the getprinc command you can view detailed information about the principal host/kdc.domain.org

$ kadmin.local:  getprinc host/kdc.domain.org
Principal: host/kdc.domain.org@DOMAIN.ORG
Expiration date: [never]
Last password change: Thu May 02 15:54:12 UTC 2024
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Thu May 02 15:54:12 UTC 2024 (kadmin/admin@DOMAIN.ORG)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 2, aes256-cts-hmac-sha1-96
Key: vno 2, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes:
Policy: [none]

You’re done with kerberos setup.

If you liked the article, you can support the author by clapping below 👏🏻 Thanks for reading!

Oleh Dubetsky|Linkedin