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