Wiki-Quellcode von Geändert: LDAP Admin-Benutzer und ReadOnly-Benutzer im logosrv

Version 52.1 von Jonas Mayer am 2022/05/04 14:46

version	line-number	content
33.1	1	(% style="color:#000000" %)Um externe oder interne Dienste über das LDAPS-Protokoll einzubinden, gibt es seit Puppet-Version 1.3.22 neben dem sogenannten LDAP-Admin Konto einen neu hinzugefügten ReadOnly-Benutzer zur Anmeldung am integrierten OpenLDAP-Verzeichnisdienst.
3.1	2
33.1	3	(% style="color:#000000" %)In diesem Artikel erfahren Sie, wo Sie die Benutzernamen & Kennwörter der zwei Benutzer finden und welches Konto sich für welches Vorhaben am besten eignen.
3.1	4
34.2	5	----
	6
46.1	7	{{toc start="2"/}}
34.2	8
	9
25.1	10	(% style="color:#000000" %)[[image:Grafik für LDAp.png\|\|height="331" width="622"]]
3.1	11
20.2	12
48.1	13	== (% style="color:#000000" %)__Übersicht der Benutzer__(%%) ==
3.1	14
	15
52.1	16	=== (% style="color:#000000" %)LDAP-Admin Benutzer(%%) ===
48.1	17
49.1	18	(% style="color:#000000; font-size:20px" %)__Nutzungsgebiet:__
48.1	19
32.1	20	(% style="color:#000000" %)Der LDAP-Admin Benutzer ist mit äußerster Vorsicht einzusetzen, da dieser einen beinahe uneingeschränkten (Schreib-)Zugriff auf den Inhalt des OpenLDAP-Verzeichnisdienst sowie die Nutzerattribute besitzt. Daher sollte der Benutzer möglichst nur intern durch LogoDIDACT-integrierte Dienste zum Einsatz kommen.
3.1	21
32.1	22	(% style="color:#000000" %)Sollten die Daten des LDAP-Admins in unbefugte Hände gelangen, stellt dies ein massives datenschutz- und sicherheitstechnisches Problem dar. __Von einem externen Gebrauch des Benutzerkontos ist daher strengstens abzuraten!__
3.1	23
	24
49.1	25	(% class="wikigeneratedid" id="HZugangsdaten:" %)
	26	(% style="color:#000000; font-size:20px" %)__Zugangsdaten:__
3.1	27
48.1	28	(% class="wikigeneratedid" id="HBenutzername" %)
32.1	29	(% style="color:#000000" %)Der Benutzername des LDAP Admins lautet:
3.1	30
3.2	31	{{code language="bash"}}
14.2	32	cn=ldap-admin
3.2	33	{{/code}}
3.1	34
	35
48.1	36	(% class="wikigeneratedid" id="HAttributedesBenutzernamens" %)
49.1	37	(% style="color:#000000; font-size:16px" %)__Vollständiger Benutzername__
14.2	38
32.1	39	(% style="color:#000000" %)Die BaseDN als Einstiegspunkt zum LDAP-Verzeichnisdienst kann über ein zusätzliches Programm ausgelesen werden, z.B. über das freie Tool LDAP Admin. In diesem Beispiel lautet die BaseDN {{code language="bash"}}dc=schule,dc=local{{/code}}. Dies kann von Installation zu Installation abweichen und wird durch die intern verwendete DNS Domain bestimmt, hier im Beispiel handelt es sich um den Standardwert.
14.2	40
30.1	41	(% style="color:#000000" %)[[image:1651243652049-471.png]]
14.2	42
	43
32.1	44	(% style="color:#000000" %)In diesem Beispiel ergibt sich der vollständige Benutzername (sogenannter //Distinguished Name// des Benutzerkontos) durch Anfügen der BaseDN:
27.1	45
	46	{{code language="bash"}}
	47	cn=ldap-admin,dc=schule,dc=local
	48	{{/code}}
	49
	50
48.1	51	(% class="wikigeneratedid" id="HKennwort" %)
49.1	52	(% style="color:#000000; font-size:16px" %)__Kennwort__
14.2	53
3.2	54	(% style="color:#000000" %)Das Kennwort ist im logosrv unter folgendem Pfad einsehbar:
3.1	55
3.2	56	{{code language="bash"}}
	57	root@logosrv:~ # cat /etc/ldap.secret
	58	{{/code}}
3.1	59
32.1	60	(% style="color:#000000" %)Optional kann man das Passwort (sowie die gültige BaseDN als Suffix des Benutzernamens) auch mit folgendem Befehl unter dem Punkt "Credentials" einsehen:
3.1	61
4.1	62	{{code language="bash"}}
	63	root@logosrv:~ # ldconf -o
	64	{{/code}}
	65
	66
50.1	67	=== (% style="color:#000000" %)LDAP-ReadOnly (ldap-ro) Benutzer(%%) ===
3.1	68
50.1	69	(% class="wikigeneratedid" id="HNutzungsgebiet:" %)
51.1	70	(% style="color:#000000; font-size:20px" %)__Nutzungsgebiet:__
3.1	71
14.2	72	(% style="color:#000000" %)Der LDAP-ReadOnly Benutzer ist für die Verwendung von externen Diensten/Anbindungen gedacht.
3.1	73
32.1	74	(% style="color:#000000" %)Mögliche Nutzungsszenarien wären unter anderem die Anbindung von extern gehosteten Webdiensten (z.B. Moodle, WebUntis oder Nextcloud) an die LogoDIDACT-integrierte Benutzerdatenbank über das LDAP-Protokoll.
14.2	75
3.2	76
11.1	77
50.1	78	(% class="wikigeneratedid" id="HBenutzername26Passwort:" %)
51.1	79	(% style="color:#000000; font-size:20px" %)__Zugangsdaten:__
3.2	80
50.1	81	(% class="wikigeneratedid" id="HBenutzername" %)
	82	(% style="color:#000000" %)Der Benutzername des LDAP ReadOnly Benutzers lautet:
	83
3.1	84	{{code language="bash"}}
14.2	85	cn=ldap-ro
3.1	86	{{/code}}
	87
32.1	88	====== (% id="cke_bm_979S" style="color:#000000; display:none" %)__ __(%%) ======
3.1	89
14.2	90
50.1	91
	92	(% class="wikigeneratedid" id="HAttributedesBenutzernamens" %)
51.1	93	(% style="color:#000000; font-size:16px" %)__Vollständiger Benutzername__
50.1	94
32.1	95	(% style="color:#000000" %)Die BaseDN als Einstiegspunkt zum LDAP-Verzeichnisdienst kann über ein zusätzliches Programm ausgelesen werden, z.B. über das freie Tool LDAP Admin. In diesem Beispiel lautet die BaseDN {{code language="bash"}}dc=schule,dc=local{{/code}}. Dies kann von Installation zu Installation abweichen und wird durch die intern verwendete DNS Domain bestimmt, hier im Beispiel handelt es sich um den Standardwert.
19.1	96
30.1	97	(% style="color:#000000" %)[[image:1651243652049-471.png]]
14.2	98
	99
32.1	100	(% style="color:#000000" %)Im Unterschied zum vorherigen Benutzer steckt das Konto verschachtelt in der OU //services//. Dadurch ergibt sich nachfolgender, vollständiger Benutzername (sogenannter //Distinguished Name//):
27.1	101
	102	{{code language="bash"}}
32.1	103	cn=ldap-ro,ou=services,dc=schule,dc=local
27.1	104	{{/code}}
	105
	106
50.1	107	(% class="wikigeneratedid" id="HKennwort" %)
51.1	108	(% style="color:#000000; font-size:16px" %)__Kennwort__
14.2	109
3.2	110	(% style="color:#000000" %)Das Kennwort ist im logosrv unter folgendem Pfad einsehbar:
	111
3.1	112	{{code language="bash"}}
	113	root@logosrv:~ # cat /etc/ldap.ro.secret
	114	{{/code}}
19.2	115
	116
51.1	117	(% style="color:#000000" %)Im Zuge der Anbindung externer Dienste sollte stets darauf geachtet werden, die verschlüsselte Form des LDAP-Protokolls (d.h. LDAPS auf TCP-Port 636) zu verwenden, damit sensible Information wie Benutzer-Zugangsdaten prinzipiell per SSL-Transportverschlüsselung versendet werden. Zur Nutzung der SSL-Transportverschlüsselung ist es wiederum wichtig, ein gültiges Let's Encrypt Zertifikat zu beantragen, damit die Verbindungssicherheit zwischen zwei Servern gewährleistet werden kann.
19.2	118
33.1	119
52.1	120
	121
	122
34.2	123	== __Ports über Firewall an Rev-Proxy weiterleiten__ ==
19.2	124
51.1	125	Damit externe LDAPS-Verbindungen zum Server möglich werden, muss der TCP-Port 636 vom vorgeschalteten Router auf die externe IP-Adresse des LogoDIDACT Servers weitergeleitet werden. Vom ldhost wird die Verbindung dann entgegengenommen und abermals an den Rev-Proxy LXC-Container weitergeleitet. Die Einrichtung der zugehörige Poerweiterleitungs-Regel wird nachfolgend beschrieben.
19.2	126
34.2	127
51.1	128	Wechseln Sie vom ldhost aus in das Verzeichnis der Shorewall:
34.2	129
	130	{{code language="bash"}}
	131	root@ldhosts:~ # cd /etc/shorewall
	132	{{/code}}
	133
	134
	135	Öffnen Sie die Datei rules mit einem Editor ihrer Wahl:
	136
	137	{{code language="bash"}}
	138	root@ldhost:/etc/shorewall # vim rules
	139	{{/code}}
	140
	141
51.1	142	Ergänzen Sie die Liste innerhalb der Datei um den obersten DNAT-Eintrag (lila eingefärbte Zeile). Dadurch werden externe Verbindungsanfragen auf Port 636 (LDAPS) vom ldhost zum rev-proxy LXC-Container weitergeleitet, so wie im Schaubild am Anfang des Artikels abgebildet. Falls diese Regel bereits vorhanden ist, können Sie den Schritt überspringen.
34.2	143
45.1	144	(% class="box" %)
	145	(((
	146	(% style="color:#16a085" %)###
46.1	147	# Shorewall version 4.0##(%%)
51.1	148	(% style="color:#16a085" %)#(%%)
	149	(% style="color:#8e44ad" %)##DNAT ext dmz:172.28.29.3 tcp 636##(%%)##
34.2	150	DNAT ext dmz:172.28.29.3 tcp 80,443
	151	DNAT ext dmz:172.28.29.2 tcp 1:21
	152	DNAT ext dmz:172.28.29.2 tcp 23:2221
	153	DNAT ext dmz:172.28.29.2 tcp 2223:65535
45.1	154	DNAT ext dmz:172.28.29.2 udp 1:65535##
	155	)))
34.2	156
	157
	158	Starten Sie nun die Firewall des ldhost neu:
	159
	160	{{code language="bash"}}
	161	root@ldhosts:~ # /etc/init.d/shorewall restart
	162	{{/code}}
	163
35.2	164
	165	== __Zertifikat für Rev-Proxy erstellen und prüfen__ ==
	166
	167	Damit die Verbindung gesichert werden kann, wird ein Let's Encrypt Zertifikat benötigt. Dieses können Sie nach folgender Anleitung erstellen:
	168
52.1	169	=== __acmetool__ ===
35.2	170
	171	Wechseln Sie in den puppeteer Container:
	172
	173	{{code language="bash"}}
	174	root@ldhost:~ # lxc-ssh -n puppeteer
	175	{{/code}}
	176
	177	Fordern Sie das Zertifikat mit folgendem Befehl an (Ersetzen Sie "SCHULKUERZEL" mit dem jeweiligen Shortname):
	178
	179	{{code language="bash"}}
	180	root@puppeteer:~ # acmetool want kopano.SCHULKUERZEL.logoip.de
	181	{{/code}}
	182
52.1	183	=== __acme.sh__ ===
35.2	184
	185	Wechseln Sie in den puppeteer Container:
	186
	187	{{code language="bash"}}
	188	root@ldhost:~ # lxc-ssh -n puppeteer
	189	{{/code}}
	190
	191
	192	Wechseln Sie im puppeteer Container in die Umgebung für das Verwalten der Zertifikate:
	193
	194	{{code language="bash"}}
	195	root@puppeteer:~ # sle
	196	{{/code}}
	197
	198
	199	Beantragen Sie ein neues Zertifikat mit folgendem Befehl (Ersetzen Sie "SCHULKUERZEL" mit dem jeweiligen Shortname):
	200
	201	{{code language="bash"}}
	202	le-acme@puppeteer:~ $ issue kopano.SCHULKUERZEL.logoip.de
	203	{{/code}}
	204
	205
	206	Um das verteilen der Zertifikate zu beschleunigen können Sie ggf. einen prun im puppeteer und rev-proxy Container durchführen:
	207
	208	{{code language="bash"}}
	209	root@puppeteer:~ # prun
	210	root@rev-proxy:~ # prun
	211	{{/code}}
	212
	213
34.2	214	== (% style="color:#000000" %)__LDAP Attribute__(%%) ==
	215
21.2	216	(% style="color:#000000" %)Standardmäßig werden folgende Attribute an die externe LDAP Schnittstelle weitergegeben:
19.2	217
	218	{{code language="bash"}}
	219	entry, cn, displayName, gidnumber, givenName, mail, member, memberOf, memberUid, o, objectClass, ou, sn, title, uid, uidnumber, uniqueMember, ldObjectType, ldRole
	220	{{/code}}
21.2	221
	222
25.1	223	(% style="color:#000000" %)Sollen zusätzliche Attribute an die externe Schnittstelle weitergegeben werden, so müssen Sie diese in folgender Datei im Puppeteer Container wie folgt abändern/erstellen:
21.2	224
	225	{{code language="bash"}}
	226	root@puppeteer:~ # vim /etc/logodidact/hiera/custom.d/ldhost.yaml
	227
	228	#Ist die Datei nicht vorhanden bitte wie folgt anpassen (Im Beispiel werden die Attribute ldBirthday & ldGender hinzugefügt):
	229
	230	---
	231	ld_legacy::ldap::ldap_ro_atts:
	232	- ldBirtday
	233	- ldGender
	234	{{/code}}
	235
	236
25.1	237	(% style="color:#000000" %)Danach müssen Sie die Änderungen ins Git übernehmen:
21.2	238
	239	{{code language="bash"}}
	240	root@puppeteer:~ # cd /etc/logodidact/
	241	root@puppeteer:/etc/logodidact # git add .
	242	root@puppeteer:/etc/logodidact # git coomit -am "LDAP Attribute in der ldhost.yaml hinzugefügt"
	243	{{/code}}
	244
24.1	245
25.1	246	(% style="color:#000000" %)Um den Prozess zu beschleunigen bietet sich ein prun im ldhost an. Damit werden die Änderungen sofort an den logosrv weitergeleitet:
24.1	247
21.2	248	{{code language="bash"}}
	249	root@ldhost:~ # prun
	250	{{/code}}
	251
	252
32.1	253	(% style="color:#000000" %)Die angepassten ACL-Änderungen können zur Kontrolle im logosrv in der Konfigurationsdatei slapd.puppet.conf angeschaut werden:
21.2	254
	255	{{code language="bash"}}
	256	root@logosrv:~ # cat /etc/ldap/slapd.puppet.conf
	257	{{/code}}