0 Votes

Wiki source code of KerberosAndLDAP

Last modified by Sirius Rayner-Karlsson on 2024/05/09 10:54

version	line-number	content
30.1	1	{{box cssClass="floatinginfobox" title="Contents"}}
22.1	2	{{toc/}}
30.1	3	{{/box}}
22.1	4
1.1	5	= Debian =
	6
26.1	7	The guide I followed was https://wiki.debian.org/LDAP/OpenLDAPSetup#Kerberos which while it worked required some minor tweaks. I obtained edit privileges for the Debian Wiki and updated the guide with the fixes that I found. I however have a Synology NAS and that can run an LDAP Server. So this guide differs from the upstream Debian Guide.
23.1	8
26.1	9	Assumption is that you have installed the LDAP Server package on your NAS and gone through initial configuration steps, so it has a domain, there is a DN you can bind as and so forth. It is also assumed you have a Debian system (12.5 or later, though this guide should work with 11.x and likely 10.x as well) that will become your KDC and KAdmin server.
14.1	10
26.1	11	Recommendation is that you create actual ##.ldif## files rather than use here-documents as used in this guide. It is far easier to make adjustments to things if you have a file to edit rather than having to type it all out again or paste it and then have to try and make edits to it without making mistakes.
2.1	12
26.1	13	The guide is for illustration. Expectation is that you do not follow it verbatim but adapt it to your needs.
20.1	14
23.1	15
34.1	16	=== Install packages ===
26.1	17
24.1	18	(% class="wikigeneratedid" %)
26.1	19	The packages you need are [[krb5-kdc-ldap>>url:https://packages.debian.org/krb5-kdc-ldap]], [[krb5-admin-server>>url:https://packages.debian.org/krb5-admin-server]] for the actual KDC and [[schema2ldif>>url:https://packages.debian.org/schema2ldif]] plus [[slapd>>https://packages.debian.org/search?keywords=slapd]] for adding the schema and ##slappasswd##. They are to be installed on your designated Debian host.
24.1	20
21.1	21	(% style="color:#400" %)
13.1	22	##{{{$ sudo apt install krb5-kdc-ldap krb5-admin-server schema2ldif}}}##
3.1	23
13.1	24
35.1	25	=== Load kerberos LDAP schema ===
3.1	26
35.1	27	Now you need to load the kerberos schema into the LDAP server on the Synology. Use the ##cn=config## DN.
26.1	28
21.1	29	(% style="color:#400" %)
36.1	30	##{{{$ zcat /usr/share/doc/krb5-kdc-ldap/kerberos.openldap.ldif.gz \| ldapadd -H ldaps://nas.example.com/ -D cn=config -W Enter LDAP Password: adding new entry "cn=kerberos,cn=schema,cn=config" $}}}##
3.1	31
	32
34.1	33	=== Create Index on krbPrincipalName ===
14.1	34
35.1	35	Having an index on the ##krbPrincipalName## improves performance. Synology OpenLDAP does not use ##mdb## format, it uses ##bdb##. Debian ##slapd## uses ##mdb## format. It is different database format, but the principle is the same. Again, as you are modifying config, the DN is ##cn=config##. Use the main password you set for the Synology LDAP server. Create a file ##step1.ldif## with the following content:
23.1	36
21.1	37	(% style="color:#400" %)
37.1	38	##{{{
	39	dn: olcDatabase={1}bdb,cn=config
	40	add: olcDbIndex
	41	olcDbIndex: krbPrincipalName eq,pres,sub}}}##
3.1	42
36.1	43
35.1	44	and apply it with
3.1	45
35.1	46	(% style="color:#400" %)
37.1	47	##{{{$ ldapmodify -H ldaps://nas.example.com/ -D cn=config -W -f step1.ldif
	48	Enter LDAP Password:
35.1	49
37.1	50	modifying entry "olcDatabase={1}bdb,cn=config"
35.1	51
37.1	52	$ }}}##
	53
	54
34.1	55	=== Create principals kadmin and kdc ===
23.1	56
35.1	57	Next, you create and configure two entries which will be used by the Kerberos servers to connect to OpenLDAP. Not running the Kerberos KDC and Admin Server on the same host as OpenLDAP, these steps are required. Keeping things confined, everything will be created under a separate ##organizationalUnit##. My guide differs from the official Debian guide here. Due to Synology OpenLDAP having a strict password policy, it was necessary to adjust the DNs of ##kdc## and ##kadmin##. The official guide use placeholder passwords which does not work with the Synology LDAP server.
	58	Generate the passwords upfront with ##slappasswd -h {SSHA}##. Then create a file ##step2.ldif## with the following content:
4.1	59
21.1	60	(% style="color:#400" %)
37.1	61	##{{{
	62	dn: ou=kerberos,dc=example,dc=com
	63	objectClass: organizationalUnit
	64	objectClass: top
	65	ou: kerberos
27.1	66
37.1	67	dn: cn=kdc,ou=kerberos,dc=example,dc=com
	68	cn: kdc
	69	sn: kdc
	70	objectClass: person
	71	objectClass: pwdPolicy
	72	pwdAttribute: userPassword
	73	pwdMinLength: 8
	74	pwdCheckQuality: 2
	75	pwdPolicySubentry: cn=kdc,ou=kerberos,dc=example,dc=com
	76	userPassword: {SSHA}<password-hash>
	77	description: Kerberos KDC Account
	78
	79	dn: cn=kadmin,ou=kerberos,dc=example,dc=com
	80	cn: kadmin
	81	sn: kadmin
	82	objectClass: person
	83	objectClass: pwdPolicy
	84	pwdAttribute: userPassword
	85	pwdMinLength: 8
	86	pwdCheckQuality: 2
	87	pwdPolicySubentry: cn=kadmin,ou=kerberos,dc=example,dc=com
	88	userPassword: {SSHA}<password-hash>
	89	description: Kerberos KDC Account}}}##
	90
	91
35.1	92	Apply it with
17.1	93
27.1	94	(% style="color:#400" %)
37.1	95	##{{{$ ldapadd -H ldaps://nas.example.com/ -D uid=root,cn=users,dc=example,dc=com -W -f step2.ldif
	96	Enter LDAP Password:
19.1	97
37.1	98	adding new entry "ou=kerberos,dc=example,dc=com"
27.1	99
37.1	100	adding new entry "cn=kdc,ou=kerberos,dc=example,dc=com"
27.2	101
37.1	102	adding new entry "cn=kadmin,ou=kerberos,dc=example,dc=com"
	103
	104	$ }}}##
	105
	106
	107	A small note on this section:
	108	The ##objectClass: pwdPolicy## must be added to a, to LDAP, physical thing. ##objectClass: person## fits the criteria, but can not have ##uid##. So to make it work, the ##uid## is replaced with ##sn## and ##cn## (yes, both are needed). Then you can set the other four attributes and add the hashed password you got from ##slappasswd##.
	109
	110
34.1	111	=== Grant kdc and kadmin permissions ===
27.2	112
37.1	113	This switches back to the ##cn=config## DN as you are changing the permissions. Note that we now reference our kdc and kadmin accounts and we grant them permission to the krbContainer which will house all our kerberos principals. Give both of them write access, because we do want to have the ability to track last login and lock accounts if there are too many login failures. We like security.
27.2	114
37.1	115	Create ##step3.ldif## with the following content:
27.2	116
37.1	117	(% style="color:#400" %)
	118	##{{{
27.2	119	dn: olcDatabase={1}bdb,cn=config
	120	add: olcAccess
	121	olcAccess: {0}to attrs=krbPrincipalKey
	122	by anonymous auth
37.1	123	by dn.exact="cn=kdc,ou=kerberos,dc=example,dc=com" write
	124	by dn.exact="cn=kadmin,ou=kerberos,dc=example,dc=com" write
27.2	125	by self write
	126	by * none
	127	-
	128	add: olcAccess
	129	olcAccess: {1}to dn.subtree="cn=krbContainer,ou=kerberos,dc=example,dc=com"
37.1	130	by dn.exact="cn=kdc,ou=kerberos,dc=example,dc=com" write
	131	by dn.exact="cn=kadmin,ou=kerberos,dc=example,dc=com" write
27.2	132	by * none
37.1	133	}}}##
27.2	134
	135
37.1	136	Do not get the domain part above wrong. If you do, you may not be able to use ##kadmin## or ##kinit## and fixing the permissions without breaking something else is a nervous task. Trust me on this (as I screwed them up).
	137
	138	Apply it with
	139
	140	(% style="color:#400" %)
	141	##{{{
	142	$ ldapmodify -H ldaps://nas.example.com -W -D cn=config -f step3.ldif
27.2	143	Enter LDAP Password:
37.1	144
27.2	145	modifying entry "olcDatabase={1}bdb,cn=config"
	146
37.1	147	$ }}}##
27.2	148
	149
34.1	150	=== Create krb5.conf ===
29.1	151
37.1	152	Next we create (or modify) ##/etc/krb5.conf## so that it will point to the right thing later. It should look something like this:
29.1	153
37.1	154	(% style="color:#400" %)
	155	##{{{
	156	[libdefaults]
	157	default_realm = EXAMPLE.COM
	158	dns_lookup_realm = false
	159	dns_lookup_kdc = false
	160	ticket_lifetime = 24h
	161	forwardable = true
	162	proxiable = true
	163	rdns = false
29.1	164
	165	[realms]
37.1	166	EXAMPLE.COM = {
	167	kdc = debian.example.com
	168	admin_server = debian.example.com
	169	default_domain = example.com
	170	}
	171	[domain_realm]
	172	.example.com = EXAMPLE.COM
	173	example.com = EXAMPLE.COM
	174	}}}##
29.1	175
	176
37.1	177	Make sure your designated debian server have ports 88, 464 and 749 open, both for TCP and UDP, in its firewall. 88 is for the kdc, 464 and 749 is for kadmin.
33.1	178
37.1	179
34.1	180	=== Create kdc.conf ===
33.1	181
37.1	182	Now we do /etc/krb5kdc/kdc.conf. Something like this should work
29.1	183
37.1	184	(% style="color:#400" %)
	185	##{{{
29.1	186	[libdefaults]
	187
	188	[realms]
37.1	189	EXAMPLE.COM = {
	190	database_module = openldap_ldapconf
	191	max_life = 7d
	192	max_renewable_life = 6d
29.1	193	}
	194
	195	[dbdefaults]
37.1	196	ldap_kerberos_container_dn = cn=krbContainer,ou=kerberos,dc=example,dc=com
29.1	197
	198	[dbmodules]
	199	openldap_ldapconf = {
	200	db_library = kldap
	201	disable_last_success = false
	202	disable_lockout = false
	203	ldap_conns_per_server = 5
37.1	204	ldap_servers = ldaps:~/~/nas.example.com
	205	ldap_kdc_dn = "cn=kdc,ou=kerberos,dc=example,dc=com"
	206	ldap_kadmind_dn = "cn=kadmin,ou=kerberos,dc=example,dc=com"
29.1	207	ldap_service_password_file = /etc/krb5kdc/service.keyfile
	208	}
37.1	209	}}}##
29.1	210
	211
34.1	212	=== Create kadm5.acl ===
33.1	213
37.1	214	Create ##/etc/krb5kdc/kadm5.acl with the following content so that kerberos administrator principals can run ##kadmin##
29.1	215
37.1	216	(% style="color:#400" %)
	217	##{{{
	218	/admin@EXAMPLE.COM
	219	}}}##
29.1	220
	221
34.1	222	=== Create the kerberos domain ===
33.1	223
37.1	224	Now we are ready to create the domain. And that we do with ##kdb5_ldap_util## as ##root##. Note that this commandline is deceptive and you need all of it.
29.1	225
37.1	226	(% style="color:#400" %)
	227	##{{{
	228	# kdb5_ldap_util -D uid=root,cn=users,dc=example,dc=com -H ldaps://nas.example.com -r EXAMPLE.COM create -subtrees dc=example,dc=com -maxtktlife '7 Days' -maxrenewlife '6 Days' -s
29.1	229	Password for "uid=root,cn=users,dc=trudheim,dc=com":
37.1	230	Initializing database for realm 'EXAMPLE.COM'
29.1	231	You will be prompted for the database Master Password.
	232	It is important that you NOT FORGET this password.
	233	Enter KDC database master key:
	234	Re-enter KDC database master key to verify:
37.1	235	# }}}##
29.1	236
	237
37.1	238	=== Stash the passwords for ##kdc## and ##kadmin## ===
29.1	239
37.1	240	Most likely, you will want your KDC and KAdmin server to start at boot, and for that, we can stash the passwords (into LDAP) for ##cn=kdc,ou=kerberos,dc=example,dc=com## and ##cn=kdc,ou=kerberos,dc=example,dc=com## using the same tool as in the previous step.
33.1	241
37.1	242	(% style="color:#400" %)
	243	##{{{
	244	# kdb5_ldap_util -D uid=root,cn=users,dc=example,dc=com -H ldaps://nas.example.com stashsrvpw -f /etc/krb5kdc/service.keyfile cn=kdc,ou=kerberos,dc=example,dc=com
	245	Password for "uid=root,cn=users,dc=example,dc=com":
	246	Password for "cn=kdc,ou=kerberos,dc=example,dc=com":
	247	Re-enter password for "cn=kdc,ou=kerberos,dc=example,dc=com":
	248	# kdb5_ldap_util -D uid=root,cn=users,dc=example,dc=com -H ldaps://nas.example.com stashsrvpw -f /etc/krb5kdc/service.keyfile cn=kadmin,ou=kerberos,dc=example,dc=com
	249	Password for "uid=root,cn=users,dc=example,dc=com":
	250	Password for "cn=kadmin,ou=kerberos,dc=example,dc=com":
	251	Re-enter password for "cn=kadmin,ou=kerberos,dc=example,dc=com":
	252	# }}}##
	253
	254
	255	=== Start the services ===
	256
	257	We are now ready to start the services. If this does not work, you need to backtrack and find out where you made a mistake, rectify it, and then walk forward again.
	258
	259	(% style="color:#400" %)
	260	##{{{
	261	# systemctl enable --now krb5-kdc krb5-admin-server
	262	#
	263	}}}##
	264
	265
	266	Check that they are running and not giving off errors with ##systemctl status krb5-kdc## and ##systemctl status krb5-admin-server##.
	267
	268
34.1	269	=== Create the first regular principals ===
33.1	270
37.1	271	Providing you got to here without issues it is now time to generate your principals that you will use to authenticate into systems with. Run ##kadmin.local## as root to create first a regular user, and then an admin version of that user.
34.1	272
37.1	273	(% style="color:#400" %)
	274	##{{{
34.1	275	# kadmin.local
	276
37.1	277	Authenticating as principal root/admin@EXAMPLE.COM with password.
34.1	278	kadmin.local: addprinc user
	279
37.1	280	No policy specified for user@EXAMPLE.COM; defaulting to no policy
	281	Enter password for principal "user@EXAMPLE.COM":
	282	Re-enter password for principal "user@EXAMPLE.COM":
	283	Principal "user@EXAMPLE.COM" created.
34.1	284
	285	kadmin.local: addprinc user/admin
37.1	286	No policy specified for user/admin@EXAMPLE.COM; defaulting to no policy
	287	Enter password for principal "user/admin@EXAMPLE.COM":
	288	Re-enter password for principal "user/admin@EXAMPLE.COM":
	289	Principal "user/admin@EXAMPLE.COM" created.
34.1	290	kadmin.local: q
	291
37.1	292	# }}}##
34.1	293
	294
37.1	295	Worth to note here is that ##user@EXAMPLE.COM## and ##user/admin@EXAMPLE.COM## can have (and probably should have) different passwords. The admin variant is allowed to do things to the kerberos database and should therefore have greater security. This is why you want to have the registering of failures to login enabled. Should you have the system exposed to the internet, you can and should expect intrusion attempts. Having Kerberos deployed makes it harder for perpetrators to gain access, but not impossible.
34.1	296
37.1	297	If you later kerberise your storage and leverage it for NFS4 mounts from your NAS, you can have NFS exposed to the internet as well. Unless someone has a valid kerberos ticket, even if they somehow could mount a share, they see nothing on it without the krbtgt.
34.1	298
37.1	299
34.1	300	=== Test your new principal ===
	301
37.1	302	Acid test is, can you authenticate with kinit?
34.1	303
37.1	304	(% style="color:#400" %)
	305	##{{{
	306	$ kinit user@EXAMPLE.COM
	307
34.1	308	Password for user@EXAMPLE.COM:
	309
	310	$ klist
	311	Ticket cache: FILE:/tmp/krb5cc_1000
	312	Default principal: user@EXAMPLE.COM
	313
	314	Valid starting Expires Service principal
	315	09/05/24 08:07:35 10/05/24 08:07:35 krbtgt/EXAMPLE.COM@EXAMPLE.COM
	316
37.1	317	$ }}}##
34.1	318
	319
37.1	320	Congratulations - you now have Kerberos working, and to boot, the database sits in LDAP. Which you can inspect with something like:
	321
	322	(% style="color:#400" %)
	323	##{{{
	324	$ ldapsearch -H ldaps://nas.example.com -D uid=root,cn=users,dc=example,dc=com -W -b ou=kerberos,dc=example,dc=com
	325	}}}##
	326
	327
34.1	328	=== Set up pam and sssd ===
	329
37.1	330	To fully leverage your shiny new KDC, you will want to install the Kerberos authentication pieces for ##PAM## and also ##sssd## to facilitate caching of authentication, in case your KDC is offline for some reason when you try to authenticate into another system.
	331
	332	(% style="color:#400" %)
	333	##{{{
	334	$ sudo apt install krb5-user libpam-krb5 sssd-krb5
	335	...
	336	$ sudo pam-auth-update
	337	}}}##
	338
	339
	340	With ##pam-auth-update## you want to enable Kerberos and SSS authentication (and flip on the auto-creation of home directories while you are there). If you now want to test login on another system with kerberos, you need ##/etc/krb5.conf## and the ##krb5-user##, ##libpam-krb5## and ##sssd-krb5## packages installed on this new system and you need to run ##pam-auth-update## to enable Kerberos and SSS. After that, the system does not need local ##user## (in /etc/passwd) - the kerberos ##user## will work instead.
	341
	342	/S

Wiki source code of KerberosAndLDAP

Quick Links

Recent Blog Posts