Wiki-Quellcode von Geändert: LDAP Admin-Benutzer und ReadOnly-Benutzer im logosrv
Version 45.1 von Jonas Mayer am 2022/05/04 09:27
Verstecke letzte Bearbeiter
author | 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 | |||
7 | {{toc start="3"/}} | ||
8 | |||
9 | |||
![]() |
25.1 | 10 | (% style="color:#000000" %)[[image:Grafik für LDAp.png||height="331" width="622"]] |
![]() |
3.1 | 11 | |
![]() |
20.2 | 12 | === === |
13 | |||
![]() |
34.2 | 14 | == (% style="color:#000000" %)__**LDAP-Admin Benutzer**__(%%) == |
![]() |
3.1 | 15 | |
16 | |||
![]() |
3.2 | 17 | === (% style="color:#000000" %)__Nutzungsgebiet:__(%%) === |
![]() |
3.1 | 18 | |
![]() |
32.1 | 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. |
![]() |
3.1 | 20 | |
![]() |
32.1 | 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!__** |
![]() |
3.1 | 22 | |
23 | |||
![]() |
14.2 | 24 | ==== (% style="color:#000000" %)__Benutzername & Kennwort__(%%) ==== |
![]() |
3.1 | 25 | |
![]() |
14.2 | 26 | ====== ====== |
27 | |||
![]() |
25.1 | 28 | ====== (% style="color:#000000" %)__Benutzername__(%%) ====== |
![]() |
14.2 | 29 | |
![]() |
32.1 | 30 | (% style="color:#000000" %)Der Benutzername des LDAP Admins lautet: |
![]() |
3.1 | 31 | |
![]() |
3.2 | 32 | {{code language="bash"}} |
![]() |
14.2 | 33 | cn=ldap-admin |
![]() |
3.2 | 34 | {{/code}} |
![]() |
3.1 | 35 | |
![]() |
14.2 | 36 | ====== ====== |
![]() |
3.1 | 37 | |
![]() |
25.1 | 38 | ====== (% style="color:#000000" %)__Attribute des Benutzernamens__(%%) ====== |
![]() |
14.2 | 39 | |
![]() |
32.1 | 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. |
![]() |
14.2 | 41 | |
![]() |
30.1 | 42 | (% style="color:#000000" %)[[image:1651243652049-471.png]] |
![]() |
14.2 | 43 | |
44 | |||
![]() |
32.1 | 45 | (% style="color:#000000" %)In diesem Beispiel ergibt sich der vollständige Benutzername (sogenannter //Distinguished Name// des Benutzerkontos) durch Anfügen der BaseDN: |
![]() |
27.1 | 46 | |
47 | {{code language="bash"}} | ||
48 | cn=ldap-admin,dc=schule,dc=local | ||
49 | {{/code}} | ||
50 | |||
51 | |||
![]() |
25.1 | 52 | ====== (% style="color:#000000" %)__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 | |||
![]() |
34.2 | 67 | == (% style="color:#000000" %)**__LDAP-ReadOnly (ldap-ro) Benutzer__**(%%) == |
![]() |
3.1 | 68 | |
69 | |||
![]() |
3.2 | 70 | ==== (% style="color:#000000" %)__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 | |
76 | |||
77 | ==== (% style="color:#000000" %)__Benutzername & Passwort:__(%%) ==== | ||
![]() |
3.2 | 78 | |
![]() |
8.1 | 79 | |
![]() |
25.1 | 80 | ====== (% style="color:#000000" %)__Benutzername__(%%) ====== |
![]() |
11.1 | 81 | |
![]() |
3.2 | 82 | (% style="color:#000000" %)Relevant für den Zugriff von Außen wäre folgender Benutzername: |
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 | |
![]() |
25.1 | 90 | ====== (% style="color:#000000" %)__Attribute des Benutzernamens__(%%) ====== |
![]() |
14.2 | 91 | |
![]() |
32.1 | 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. |
![]() |
19.1 | 93 | |
![]() |
30.1 | 94 | (% style="color:#000000" %)[[image:1651243652049-471.png]] |
![]() |
14.2 | 95 | |
96 | |||
![]() |
32.1 | 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//): |
![]() |
27.1 | 98 | |
99 | {{code language="bash"}} | ||
![]() |
32.1 | 100 | cn=ldap-ro,ou=services,dc=schule,dc=local |
![]() |
27.1 | 101 | {{/code}} |
102 | |||
103 | |||
![]() |
25.1 | 104 | ====== (% style="color:#000000" %)__Kennwort__(%%) ====== |
![]() |
14.2 | 105 | |
![]() |
3.2 | 106 | (% style="color:#000000" %)Das Kennwort ist im logosrv unter folgendem Pfad einsehbar: |
107 | |||
![]() |
3.1 | 108 | {{code language="bash"}} |
109 | root@logosrv:~ # cat /etc/ldap.ro.secret | ||
110 | {{/code}} | ||
![]() |
19.2 | 111 | |
112 | |||
![]() |
34.1 | 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. |
![]() |
33.1 | 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. |
![]() |
19.2 | 115 | |
![]() |
33.1 | 116 | |
![]() |
34.2 | 117 | == __**Ports über Firewall an Rev-Proxy weiterleiten**__ == |
![]() |
19.2 | 118 | |
![]() |
34.2 | 119 | Damit die LDAP Verbindung funktioniert, muss der Port 636 an den Rev-Proxy weitergeleitet werden. Diese Weiterleitung können Sie wie folgt einrichten: |
![]() |
19.2 | 120 | |
![]() |
34.2 | 121 | |
122 | Wechseln Sie in das Verzeichnis der Shorewall: | ||
123 | |||
124 | {{code language="bash"}} | ||
125 | root@ldhosts:~ # cd /etc/shorewall | ||
126 | {{/code}} | ||
127 | |||
128 | |||
129 | Öffnen Sie die Datei rules mit einem Editor ihrer Wahl: | ||
130 | |||
131 | {{code language="bash"}} | ||
132 | root@ldhost:/etc/shorewall # vim rules | ||
133 | {{/code}} | ||
134 | |||
135 | |||
![]() |
45.1 | 136 | Ergänzen Sie die Liste innerhalb der Datei um den obersten 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. |
![]() |
34.2 | 137 | |
![]() |
45.1 | 138 | (% class="box" %) |
139 | ((( | ||
140 | (% style="color:#16a085" %)### | ||
![]() |
34.2 | 141 | # Shorewall version 4.0 |
![]() |
45.1 | 142 | ###(%%)## |
143 | (% style="color:#8e44ad" %)**DNAT ext dmz:172.28.29.3 tcp 636**(%%) | ||
![]() |
34.2 | 144 | DNAT ext dmz:172.28.29.3 tcp 80,443 |
145 | DNAT ext dmz:172.28.29.2 tcp 1:21 | ||
146 | DNAT ext dmz:172.28.29.2 tcp 23:2221 | ||
147 | DNAT ext dmz:172.28.29.2 tcp 2223:65535 | ||
![]() |
45.1 | 148 | DNAT ext dmz:172.28.29.2 udp 1:65535## |
149 | ))) | ||
![]() |
34.2 | 150 | |
151 | |||
152 | Starten Sie nun die Firewall des ldhost neu: | ||
153 | |||
154 | {{code language="bash"}} | ||
155 | root@ldhosts:~ # /etc/init.d/shorewall restart | ||
156 | {{/code}} | ||
157 | |||
![]() |
35.2 | 158 | |
159 | == __**Zertifikat für Rev-Proxy erstellen und prüfen**__ == | ||
160 | |||
161 | Damit die Verbindung gesichert werden kann, wird ein Let's Encrypt Zertifikat benötigt. Dieses können Sie nach folgender Anleitung erstellen: | ||
162 | |||
![]() |
36.2 | 163 | ====== ====== |
![]() |
35.2 | 164 | |
165 | ====== __acmetool__ ====== | ||
166 | |||
167 | Wechseln Sie in den puppeteer Container: | ||
168 | |||
169 | {{code language="bash"}} | ||
170 | root@ldhost:~ # lxc-ssh -n puppeteer | ||
171 | {{/code}} | ||
172 | |||
173 | Fordern Sie das Zertifikat mit folgendem Befehl an (Ersetzen Sie "SCHULKUERZEL" mit dem jeweiligen Shortname): | ||
174 | |||
175 | {{code language="bash"}} | ||
176 | root@puppeteer:~ # acmetool want kopano.SCHULKUERZEL.logoip.de | ||
177 | {{/code}} | ||
178 | |||
![]() |
36.2 | 179 | ===== ===== |
![]() |
35.2 | 180 | |
181 | ====== __acme.sh__ ====== | ||
182 | |||
183 | Wechseln Sie in den puppeteer Container: | ||
184 | |||
185 | {{code language="bash"}} | ||
186 | root@ldhost:~ # lxc-ssh -n puppeteer | ||
187 | {{/code}} | ||
188 | |||
189 | |||
190 | Wechseln Sie im puppeteer Container in die Umgebung für das Verwalten der Zertifikate: | ||
191 | |||
192 | {{code language="bash"}} | ||
193 | root@puppeteer:~ # sle | ||
194 | {{/code}} | ||
195 | |||
196 | |||
197 | Beantragen Sie ein neues Zertifikat mit folgendem Befehl (Ersetzen Sie "SCHULKUERZEL" mit dem jeweiligen Shortname): | ||
198 | |||
199 | {{code language="bash"}} | ||
200 | le-acme@puppeteer:~ $ issue kopano.SCHULKUERZEL.logoip.de | ||
201 | {{/code}} | ||
202 | |||
203 | |||
204 | Um das verteilen der Zertifikate zu beschleunigen können Sie ggf. einen prun im puppeteer und rev-proxy Container durchführen: | ||
205 | |||
206 | {{code language="bash"}} | ||
207 | root@puppeteer:~ # prun | ||
208 | root@rev-proxy:~ # prun | ||
209 | {{/code}} | ||
210 | |||
211 | |||
![]() |
34.2 | 212 | === === |
213 | |||
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}} |