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