Wiki-Quellcode von Geändert: LDAP Admin-Benutzer und ReadOnly-Benutzer im logosrv
Version 44.1 von Jonas Mayer am 2022/05/04 09:21
Zeige letzte Bearbeiter
author | version | line-number | content |
---|---|---|---|
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. | ||
2 | |||
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. | ||
4 | |||
5 | ---- | ||
6 | |||
7 | {{toc start="3"/}} | ||
8 | |||
9 | |||
10 | (% style="color:#000000" %)[[image:Grafik für LDAp.png||height="331" width="622"]] | ||
11 | |||
12 | === === | ||
13 | |||
14 | == (% style="color:#000000" %)__**LDAP-Admin Benutzer**__(%%) == | ||
15 | |||
16 | |||
17 | === (% style="color:#000000" %)__Nutzungsgebiet:__(%%) === | ||
18 | |||
19 | (% 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. | ||
20 | |||
21 | (% 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!__** | ||
22 | |||
23 | |||
24 | ==== (% style="color:#000000" %)__Benutzername & Kennwort__(%%) ==== | ||
25 | |||
26 | ====== ====== | ||
27 | |||
28 | ====== (% style="color:#000000" %)__Benutzername__(%%) ====== | ||
29 | |||
30 | (% style="color:#000000" %)Der Benutzername des LDAP Admins lautet: | ||
31 | |||
32 | {{code language="bash"}} | ||
33 | cn=ldap-admin | ||
34 | {{/code}} | ||
35 | |||
36 | ====== ====== | ||
37 | |||
38 | ====== (% style="color:#000000" %)__Attribute des Benutzernamens__(%%) ====== | ||
39 | |||
40 | (% 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. | ||
41 | |||
42 | (% style="color:#000000" %)[[image:1651243652049-471.png]] | ||
43 | |||
44 | |||
45 | (% style="color:#000000" %)In diesem Beispiel ergibt sich der vollständige Benutzername (sogenannter //Distinguished Name// des Benutzerkontos) durch Anfügen der BaseDN: | ||
46 | |||
47 | {{code language="bash"}} | ||
48 | cn=ldap-admin,dc=schule,dc=local | ||
49 | {{/code}} | ||
50 | |||
51 | |||
52 | ====== (% style="color:#000000" %)__Kennwort__(%%) ====== | ||
53 | |||
54 | (% style="color:#000000" %)Das Kennwort ist im logosrv unter folgendem Pfad einsehbar: | ||
55 | |||
56 | {{code language="bash"}} | ||
57 | root@logosrv:~ # cat /etc/ldap.secret | ||
58 | {{/code}} | ||
59 | |||
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: | ||
61 | |||
62 | {{code language="bash"}} | ||
63 | root@logosrv:~ # ldconf -o | ||
64 | {{/code}} | ||
65 | |||
66 | |||
67 | == (% style="color:#000000" %)**__LDAP-ReadOnly (ldap-ro) Benutzer__**(%%) == | ||
68 | |||
69 | |||
70 | ==== (% style="color:#000000" %)__Nutzungsgebiet:__(%%) ==== | ||
71 | |||
72 | (% style="color:#000000" %)Der LDAP-ReadOnly Benutzer ist für die Verwendung von externen Diensten/Anbindungen gedacht. | ||
73 | |||
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. | ||
75 | |||
76 | |||
77 | ==== (% style="color:#000000" %)__Benutzername & Passwort:__(%%) ==== | ||
78 | |||
79 | |||
80 | ====== (% style="color:#000000" %)__Benutzername__(%%) ====== | ||
81 | |||
82 | (% style="color:#000000" %)Relevant für den Zugriff von Außen wäre folgender Benutzername: | ||
83 | |||
84 | {{code language="bash"}} | ||
85 | cn=ldap-ro | ||
86 | {{/code}} | ||
87 | |||
88 | ====== (% id="cke_bm_979S" style="color:#000000; display:none" %)__ __(%%) ====== | ||
89 | |||
90 | ====== (% style="color:#000000" %)__Attribute des Benutzernamens__(%%) ====== | ||
91 | |||
92 | (% 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. | ||
93 | |||
94 | (% style="color:#000000" %)[[image:1651243652049-471.png]] | ||
95 | |||
96 | |||
97 | (% 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//): | ||
98 | |||
99 | {{code language="bash"}} | ||
100 | cn=ldap-ro,ou=services,dc=schule,dc=local | ||
101 | {{/code}} | ||
102 | |||
103 | |||
104 | ====== (% style="color:#000000" %)__Kennwort__(%%) ====== | ||
105 | |||
106 | (% style="color:#000000" %)Das Kennwort ist im logosrv unter folgendem Pfad einsehbar: | ||
107 | |||
108 | {{code language="bash"}} | ||
109 | root@logosrv:~ # cat /etc/ldap.ro.secret | ||
110 | {{/code}} | ||
111 | |||
112 | |||
113 | (% 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. | ||
114 | 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. | ||
115 | |||
116 | |||
117 | **... [REV-PROXY LDAPS-Freischaltung mit Let's Encrypt einfügen]...** | ||
118 | |||
119 | |||
120 | == __**Ports über Firewall an Rev-Proxy weiterleiten**__ == | ||
121 | |||
122 | Damit die LDAP Verbindung funktioniert, muss der Port 636 an den Rev-Proxy weitergeleitet werden. Diese Weiterleitung können Sie wie folgt einrichten: | ||
123 | |||
124 | |||
125 | Wechseln Sie in das Verzeichnis der Shorewall: | ||
126 | |||
127 | {{code language="bash"}} | ||
128 | root@ldhosts:~ # cd /etc/shorewall | ||
129 | {{/code}} | ||
130 | |||
131 | |||
132 | Öffnen Sie die Datei rules mit einem Editor ihrer Wahl: | ||
133 | |||
134 | {{code language="bash"}} | ||
135 | root@ldhost:/etc/shorewall # vim rules | ||
136 | {{/code}} | ||
137 | |||
138 | |||
139 | Ergänzen Sie die Liste innerhalb der Datei um den obersten Eintrag (DNAT ext dmz:172.28.29.3 tcp 636): | ||
140 | |||
141 | {{code language="bash"}} | ||
142 | # | ||
143 | # Shorewall version 4.0 | ||
144 | # | ||
145 | DNAT ext dmz:172.28.29.3 tcp 636 | ||
146 | DNAT ext dmz:172.28.29.3 tcp 80,443 | ||
147 | DNAT ext dmz:172.28.29.2 tcp 1:21 | ||
148 | DNAT ext dmz:172.28.29.2 tcp 23:2221 | ||
149 | DNAT ext dmz:172.28.29.2 tcp 2223:65535 | ||
150 | DNAT ext dmz:172.28.29.2 udp 1:65535 | ||
151 | |||
152 | {{/code}} | ||
153 | |||
154 | |||
155 | Starten Sie nun die Firewall des ldhost neu: | ||
156 | |||
157 | {{code language="bash"}} | ||
158 | root@ldhosts:~ # /etc/init.d/shorewall restart | ||
159 | {{/code}} | ||
160 | |||
161 | |||
162 | == __**Zertifikat für Rev-Proxy erstellen und prüfen**__ == | ||
163 | |||
164 | Damit die Verbindung gesichert werden kann, wird ein Let's Encrypt Zertifikat benötigt. Dieses können Sie nach folgender Anleitung erstellen: | ||
165 | |||
166 | ====== ====== | ||
167 | |||
168 | ====== __acmetool__ ====== | ||
169 | |||
170 | Wechseln Sie in den puppeteer Container: | ||
171 | |||
172 | {{code language="bash"}} | ||
173 | root@ldhost:~ # lxc-ssh -n puppeteer | ||
174 | {{/code}} | ||
175 | |||
176 | Fordern Sie das Zertifikat mit folgendem Befehl an (Ersetzen Sie "SCHULKUERZEL" mit dem jeweiligen Shortname): | ||
177 | |||
178 | {{code language="bash"}} | ||
179 | root@puppeteer:~ # acmetool want kopano.SCHULKUERZEL.logoip.de | ||
180 | {{/code}} | ||
181 | |||
182 | ===== ===== | ||
183 | |||
184 | ====== __acme.sh__ ====== | ||
185 | |||
186 | Wechseln Sie in den puppeteer Container: | ||
187 | |||
188 | {{code language="bash"}} | ||
189 | root@ldhost:~ # lxc-ssh -n puppeteer | ||
190 | {{/code}} | ||
191 | |||
192 | |||
193 | Wechseln Sie im puppeteer Container in die Umgebung für das Verwalten der Zertifikate: | ||
194 | |||
195 | {{code language="bash"}} | ||
196 | root@puppeteer:~ # sle | ||
197 | {{/code}} | ||
198 | |||
199 | |||
200 | Beantragen Sie ein neues Zertifikat mit folgendem Befehl (Ersetzen Sie "SCHULKUERZEL" mit dem jeweiligen Shortname): | ||
201 | |||
202 | {{code language="bash"}} | ||
203 | le-acme@puppeteer:~ $ issue kopano.SCHULKUERZEL.logoip.de | ||
204 | {{/code}} | ||
205 | |||
206 | |||
207 | Um das verteilen der Zertifikate zu beschleunigen können Sie ggf. einen prun im puppeteer und rev-proxy Container durchführen: | ||
208 | |||
209 | {{code language="bash"}} | ||
210 | root@puppeteer:~ # prun | ||
211 | root@rev-proxy:~ # prun | ||
212 | {{/code}} | ||
213 | |||
214 | |||
215 | === === | ||
216 | |||
217 | == (% style="color:#000000" %)**__LDAP Attribute__**(%%) == | ||
218 | |||
219 | (% style="color:#000000" %)Standardmäßig werden folgende Attribute an die externe LDAP Schnittstelle weitergegeben: | ||
220 | |||
221 | {{code language="bash"}} | ||
222 | entry, cn, displayName, gidnumber, givenName, mail, member, memberOf, memberUid, o, objectClass, ou, sn, title, uid, uidnumber, uniqueMember, ldObjectType, ldRole | ||
223 | {{/code}} | ||
224 | |||
225 | |||
226 | (% 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: | ||
227 | |||
228 | {{code language="bash"}} | ||
229 | root@puppeteer:~ # vim /etc/logodidact/hiera/custom.d/ldhost.yaml | ||
230 | |||
231 | #Ist die Datei nicht vorhanden bitte wie folgt anpassen (Im Beispiel werden die Attribute ldBirthday & ldGender hinzugefügt): | ||
232 | |||
233 | --- | ||
234 | ld_legacy::ldap::ldap_ro_atts: | ||
235 | - ldBirtday | ||
236 | - ldGender | ||
237 | {{/code}} | ||
238 | |||
239 | |||
240 | (% style="color:#000000" %)Danach müssen Sie die Änderungen ins Git übernehmen: | ||
241 | |||
242 | {{code language="bash"}} | ||
243 | root@puppeteer:~ # cd /etc/logodidact/ | ||
244 | root@puppeteer:/etc/logodidact # git add . | ||
245 | root@puppeteer:/etc/logodidact # git coomit -am "LDAP Attribute in der ldhost.yaml hinzugefügt" | ||
246 | {{/code}} | ||
247 | |||
248 | |||
249 | (% style="color:#000000" %)Um den Prozess zu beschleunigen bietet sich ein prun im ldhost an. Damit werden die Änderungen sofort an den logosrv weitergeleitet: | ||
250 | |||
251 | {{code language="bash"}} | ||
252 | root@ldhost:~ # prun | ||
253 | {{/code}} | ||
254 | |||
255 | |||
256 | (% style="color:#000000" %)Die angepassten ACL-Änderungen können zur Kontrolle im logosrv in der Konfigurationsdatei slapd.puppet.conf angeschaut werden: | ||
257 | |||
258 | {{code language="bash"}} | ||
259 | root@logosrv:~ # cat /etc/ldap/slapd.puppet.conf | ||
260 | {{/code}} |