Kerberos

MIT-KRB HowTo

KDC konfigurieren und KDC Datenbank erstellen

1. /var/lib/krb5kdc/kdc.conf erstellen:

[kdcdefaults]
        kdc_ports = 89
        kdc_tcp_ports = 89
        kadmind_port = 750
        kpasswd_port = 466

[realms]
        INTERN.NEOREALM.DYNDNS.ORG = {
                database_name = /var/lib/krb5kdc/principal
                acl_file = /var/lib/krb5kdc/kadm5.acl
                key_stash_file = /var/lib/krb5kdc/.k5.INTERN.NEOREALM.DYNDNS.ORG
                kadmind_port = 750
                kpasswd_port = 466
                max_life = 10h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                #default_principal_flags = +preauth                                                                                            
                }

[logging]
              kdc = CONSOLE
              kdc = SYSLOG:INFO:DAEMON
              kdc = FILE:/var/log/kdc.log
              admin_server = FILE:/var/log/kadmin.log

1. Datenbank erstellen:

kdb5_util create -r <REALMNAME> -s

1. kadmin Prinzipal erstellen:

kadmin.local
addprinc admin/admin@INTERN.NEOREALM.DYNDNS.ORG

*/admin@INTERN.DARKREALM.DYNDNS.ORG	*

DNS einrichten

Folgende RR's in die Zone eintragen

_kerberos.intern.darkrealm.dyndns.org		TXT	"INTERN.DARKREALM.DYNDNS.ORG"
_kerberos.intern.darkrealm.dyndns.org		SRV	1 0 89 shodan.intern.darkrealm.dyndns.org.
_kerberos-adm.intern.darkrealm.dyndns.org	SRV	1 0 777 shodan.intern.darkrealm.dyndns.org. (wird noch? nicht ausgewertet) 
_kerberos.intern.darkrealm.dyndns.org		SRV	1 0 89 shodan.intern.darkrealm.dyndns.org.
_kpasswd.intern.darkrealm.dyndns.org		SRV	1 0 464 shodan.intern.darkrealm.dyndns.org.

Das reicht um Rechner ohne /etc/krb5.conf auf den default realm hinzuweisen. Weil _kerberos-adm zurzeit noch nicht ausgewertet wird muss man folgendes in der /etc/krb5.conf eintragen:

[realms]
	INTERN.DARKREALM.DYNDNS.ORG = {
		admin_server = shodan.intern.darkrealm.dyndns.org:777
	}

2. NFS mit sec=krb5p

Mount : mount shodan:/home /home -o sec=krb5p

Server: rpc.svcgssd braucht keytab /etc/krb5.keytab

rpc.svcgssd braucht explizit nfs/<fqdn> principal (erstmal egal welcher FQDN, aber der client kann nicht connecten wenn fqdn vom server nicht drinsteht)

Also in die keytab:

nfs/shodan.intern.darkrealm.dyndns.org

Client: Client sucht laut man rpc.gssd folgende Einträge in der keytab: (scheinbar geht es hier nur um machine credentials, egal wie der principal heisst)

          <HOSTNAME>$@<REALM>
          root/<hostname>@<REALM>
          nfs/<hostname>@<REALM>
          host/<hostname>@<REALM>
          root/<anyname>@<REALM>
          nfs/<anyname>@<REALM>
          host/<anyname>@<REALM>

Also in die keytab:

host/rasmatazz.intern.darkrealm.dyndns.org

KVNO's müssen auf jedem Rechner gleich sein !

Keytab auf dem Server :

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2 nfs/shodan.intern.darkrealm.dyndns.org@INTERN.DARKREALM.DYNDNS.ORG
   2    2 nfs/shodan.intern.darkrealm.dyndns.org@INTERN.DARKREALM.DYNDNS.ORG

Keytab auf dem Client :

slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2 host/rasmatazz.intern.darkrealm.dyndns.org@INTERN.DARKREALM.DYNDNS.ORG
   2    2 host/rasmatazz.intern.darkrealm.dyndns.org@INTERN.DARKREALM.DYNDNS.ORG

3. SSH mit kerberos (-K)

In der Server-Keytab reicht :

host/shodan.intern.darkrealm.dyndns.org@INTERN.DARKREALM.DYNDNS.ORG

Aber in der /etc/krb5.conf auf dem Server muss stehen :

<libdefaults>
ignore_acceptor_hostname = true

ansonsten meldet der SSH-Server daß kein keytab-entry für host/shodan@ vorhanden ist.

4. samba mit kerberos

kinit chris@HERRMANN.AD
sudo mount //shodan.intern.darkrealm.dyndns.org/temporary /mnt/tmp -o vers=3.02,sec=krb5i,cruid=chris,user=chris,cifsacl

Crossrealm AD <-> MIT-KRB5

Funktioniert momentan nur mit einem Windows Server als Domain Controller!

Auf dem MIT-KRB5 KDC

• Mit kadmin 2 Principals hinzufügen (bei beiden gleiches Passwort setzen):
  • addprinc krbtgt/INTERN.DARKREALM.DYNDNS.ORG@TESTDOMAIN.AD
  • krbtgt/TESTDOMAIN.AD@INTERN.DARKREALM.DYNDNS.ORG

Auf dem Windows-Domaincontroller

• Active Directory-Domänen und -Vertrauensstellungen öffnen
• Neue Vertrauensstellung
• Name: INTERN.DARKREALM.DYNDNS.ORG
• Vertrauenstyp: Bereichsvertrauensstellung
• Nicht transitiv oder Transitiv, ist egal
• Bidirektional
• Vertrauensstellungskennwort eingeben (gleiches wie auf der MIT-KRB5 Seite)

• Zuständigen KDC für INTERN.DARKREALM.DYNDNS.ORG festlegen:
  • ksetup /addkdc INTERN.DARKREALM.DYNDNS.ORG shodan.intern.darkrealm.dyndns.org
• Rechnernamen zu dem Realm zuordnen:
  • ksetup /addhosttorealmmap shodan.intern.darkrealm.dyndns.org INTERN.DARKREALM.DYNDNS.ORG

Tests

• Ticket aus dem INTERN.DARKREALM.DYNDNS.ORG-Realm heraus vom TESTDOMAIN.AD-Realm holen

kinit chris@INTERN.DARKREALM.DYNDNS.ORG
kvno HTTP/testdomain.ad@TESTDOMAIN.AD

Fehler

Bekommt man einen Fehler "kvno: Generic error (see e-text) while getting credentials for HTTP/vm-winserver2025.testdomain.ad@TESTDOMAIN.AD" o.ä., dann entweder:

• modprinc +no_auth_data_required krbtgt/TESTDOMAIN.AD@INTERN.DARKREALM.DYNDNS.ORG

oder in /var/lib/krb5kdc/kdc.conf im [realms]-Abschnitt für den INTERN.DARKREALM.DYNDNS.ORG-Realms folgende Zeile einfügen:

disable_pac = true

Quelle: https://bugzilla.redhat.com/show_bug.cgi?id=2016312

Beispiel-LDIF eines Trusts

dn: CN=INTERN.DARKREALM.DYNDNS.ORG,CN=System,DC=testdomain,DC=ad
objectClass: top
objectClass: leaf
objectClass: trustedDomain
cn: INTERN.DARKREALM.DYNDNS.ORG
distinguishedName: CN=INTERN.DARKREALM.DYNDNS.ORG,CN=System,DC=testdomain,DC=a
 d
instanceType: 4
whenCreated: 20250926000103.0Z
whenChanged: 20250926000103.0Z
uSNCreated: 16453
uSNChanged: 16454
showInAdvancedViewOnly: TRUE
name: INTERN.DARKREALM.DYNDNS.ORG
objectGUID:: ojk5Xjs+Z0ieoCAx6wEjsA==
trustDirection: 3
trustPartner: INTERN.DARKREALM.DYNDNS.ORG
trustPosixOffset: 0
trustType: 3
trustAttributes: 0
flatName: INTERN.DARKREALM.DYNDNS.ORG
objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=testdomain,DC=
 ad
isCriticalSystemObject: TRUE
dSCorePropagationData: 16010101000000.0Z
trustAuthIncoming:
trustAuthOutgoing:

dn: CN=INTERN.DARKREALM.DYNDNS.ORG$,CN=Users,DC=testdomain,DC=ad
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: INTERN.DARKREALM.DYNDNS.ORG$
distinguishedName: CN=INTERN.DARKREALM.DYNDNS.ORG$,CN=Users,DC=testdomain,DC=a
 d
instanceType: 4
whenCreated: 20250926005246.0Z
whenChanged: 20250926005247.0Z
uSNCreated: 24597
uSNChanged: 24599
name: INTERN.DARKREALM.DYNDNS.ORG$
objectGUID:: HPPriJ7qRU+1bDWJWV9Yvw==
userAccountControl: 2082
badPwdCount: 0
codePage: 0
countryCode: 0
badPasswordTime: 0
lastLogoff: 0
lastLogon: 0
pwdLastSet: 0
primaryGroupID: 529
objectSid:: AQUAAAAAAAUVAAAAjZWqvXpflmUzfrM8UgQAAA==
accountExpires: 9223372036854775807
logonCount: 0
sAMAccountName: INTERN.DARKREALM.DYNDNS.ORG$
sAMAccountType: 805306370
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=testdomain,DC=ad
isCriticalSystemObject: TRUE
dSCorePropagationData: 16010101000000.0Z

Squid Crossrealm

Kein Plan wie und warum es funktioniert. Ist auch noch nicht wirklich crossrealm.

In /etc/squid/squid.conf folgende Zeile einfügen:

auth_param negotiate program /usr/libexec/squid/negotiate_kerberos_auth -k /etc/squid.smb.keytab -i

msktutil -c -s HTTP/shodan.intern.darkrealm.dyndns.org -h shodan.intern.darkrealm.dyndns.org -k squid.smb.keytab --computer-name squid-http --upn HTTP/shodan.intern.darkrealm.dyndns.org --verbose --realm AD.INTERN.DARKREALM.DYNDNS.ORG --no-reverse-lookups --use-service-account

Dann erstellte Keytab nach /etc/squid.smb.keytab kopieren und squid neustarten.