89371
Jan 14, 2016, updated at Jan 15, 2016 (UTC)
7411
17
0
LDAP Authentifizierungsproblem bei Gruppen eines AD
Hallo zusammen,
ich lerne mich gerade in LDAP ein, als Test möchte ich den Dokumentenscanner (Der die Benutzer über LDAP authentifizieren kann) and den Domain Controller (Windows 2008 R2) binden.
Mit folgendem BIND können sich schon mal alle User authentifizieren, die sich im Active Directory unter "Users" befinden, das funktioniert schon mal ganz gut:
CN=User,DC=domain,DC=de
Nun wollte ich eine Sicherheitsgruppe mit dem Namen "Scanneruser" erstellen und nur bestimmten Personen das authentifizieren zulassen. Ich habe testweise eine Organisationseinheit mit dem Namen "Berechtigungen" erzeugt und die Sicherheitsgruppe dort hinein geschoben. Dann habe ich ein paar Benutzer dieser Gruppe hinzugefügt und im Scanner folgenden BIND eingegeben:
CN=Scanneruser,OU=Berechtigungen,DC=domain,DC=de
Als Kontrolle wird im Attribut Editor der distinguishedName des Scannerusers ebenfalls genau so angezeigt, doch dann kann sich niemand mehr authentifizieren. Nach meine Verständnis müssten sich alle authentifizieren können, denen ich diese Gruppenberechtigung gegeben habe?!?
Ist diese Vorgenesweise überhaupt richtig/sinvoll/praktikabel, um bestimmten Personen bestimmte Berechtigungen geben zu können?
ich lerne mich gerade in LDAP ein, als Test möchte ich den Dokumentenscanner (Der die Benutzer über LDAP authentifizieren kann) and den Domain Controller (Windows 2008 R2) binden.
Mit folgendem BIND können sich schon mal alle User authentifizieren, die sich im Active Directory unter "Users" befinden, das funktioniert schon mal ganz gut:
CN=User,DC=domain,DC=de
Nun wollte ich eine Sicherheitsgruppe mit dem Namen "Scanneruser" erstellen und nur bestimmten Personen das authentifizieren zulassen. Ich habe testweise eine Organisationseinheit mit dem Namen "Berechtigungen" erzeugt und die Sicherheitsgruppe dort hinein geschoben. Dann habe ich ein paar Benutzer dieser Gruppe hinzugefügt und im Scanner folgenden BIND eingegeben:
CN=Scanneruser,OU=Berechtigungen,DC=domain,DC=de
Als Kontrolle wird im Attribut Editor der distinguishedName des Scannerusers ebenfalls genau so angezeigt, doch dann kann sich niemand mehr authentifizieren. Nach meine Verständnis müssten sich alle authentifizieren können, denen ich diese Gruppenberechtigung gegeben habe?!?
Ist diese Vorgenesweise überhaupt richtig/sinvoll/praktikabel, um bestimmten Personen bestimmte Berechtigungen geben zu können?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 293072
Url: https://administrator.de/contentid/293072
Printed on: April 19, 2024 at 04:04 o'clock
17 Comments
Latest comment
Hi,
erstens überprüfe Deine Schreibweisen. Ich hoffe, Du hast nur hier im Forum einen Schreibfehler: CN=Users,DC=domain,DC=de.
Zweitens: Wenn Die OU "Berechtigungen" heißt, offensichtlich direkt unterhalb der Domäne (OU=Berechtigungen,DC=domain,DC=de), und dort die Benutzer drin sind, warum gibst Du dann als Bind-Root einen Benutzer ein? (CN=Scanneruser,OU=Berechtigungen,DC=domain,DC=de)
Ich denke, hier müsstest Du analog zu Deinem ersten Versuch mit "CN=Users,DC=domain,DC=de" jetzt eben "OU=Berechtigungen,DC=domain,DC=de" dort eintragen. Dann können sich alle Benutzer, welche unterhalb dieser OU sind, an der Kiste anmelden.
E.
erstens überprüfe Deine Schreibweisen. Ich hoffe, Du hast nur hier im Forum einen Schreibfehler: CN=Users,DC=domain,DC=de.
Zweitens: Wenn Die OU "Berechtigungen" heißt, offensichtlich direkt unterhalb der Domäne (OU=Berechtigungen,DC=domain,DC=de), und dort die Benutzer drin sind, warum gibst Du dann als Bind-Root einen Benutzer ein? (CN=Scanneruser,OU=Berechtigungen,DC=domain,DC=de)
Ich denke, hier müsstest Du analog zu Deinem ersten Versuch mit "CN=Users,DC=domain,DC=de" jetzt eben "OU=Berechtigungen,DC=domain,DC=de" dort eintragen. Dann können sich alle Benutzer, welche unterhalb dieser OU sind, an der Kiste anmelden.
E.
Danke erst einmal.
Stimmt, das war nur ein Tippfehler.
Deine Methode habe ich bereits ausprobiert. Wenn ich die benutzer in die OU Berechtigungen verschiebe, dann fehlen sie wo anders. Wenn ich jetzt eine größere Struktur habe sollte, dann kann ich keine Querverweise mit den Berechtigungen machen. Als Beispiel:
OU Buero 1
CN Chef 1
CN Aushilfe1
OU Buero 2
CN Chef 2
CN Aushilfe2
Ich möchte nun dass die Chefs in beiden Büros scannen dürfen, wenn sie mal zwischen den Büros hin und her fahren, aber die Aushilfen eben nicht.
Wenn ich den Bind auf root setze, dürfen dann alle scannen, und das will ich ja nicht.
Wenn ich eine OU "Chefs" mache und eine OU "Aushilfen" mache, dann sind sie nicht mehr unterhalb ihrer Buero struktur und ich kann andere Berechtigungen nicht mehr individuell setzen, z.B. Drucker1 dürfen nur Chef1 und Aushilfe1 verwenden, Drucker2 darf nur Chef2 und Aushilfe2 verwenden.
Geht das dann gar nicht?
Stimmt, das war nur ein Tippfehler.
Deine Methode habe ich bereits ausprobiert. Wenn ich die benutzer in die OU Berechtigungen verschiebe, dann fehlen sie wo anders. Wenn ich jetzt eine größere Struktur habe sollte, dann kann ich keine Querverweise mit den Berechtigungen machen. Als Beispiel:
OU Buero 1
CN Chef 1
CN Aushilfe1
OU Buero 2
CN Chef 2
CN Aushilfe2
Ich möchte nun dass die Chefs in beiden Büros scannen dürfen, wenn sie mal zwischen den Büros hin und her fahren, aber die Aushilfen eben nicht.
Wenn ich den Bind auf root setze, dürfen dann alle scannen, und das will ich ja nicht.
Wenn ich eine OU "Chefs" mache und eine OU "Aushilfen" mache, dann sind sie nicht mehr unterhalb ihrer Buero struktur und ich kann andere Berechtigungen nicht mehr individuell setzen, z.B. Drucker1 dürfen nur Chef1 und Aushilfe1 verwenden, Drucker2 darf nur Chef2 und Aushilfe2 verwenden.
Geht das dann gar nicht?
Moin,
kann man an deinem uns unbekannten Scanner denn LDAP-Filter Abfragen definieren ?
Z.B
Dann ginge das.
Gruß grexit
kann man an deinem uns unbekannten Scanner denn LDAP-Filter Abfragen definieren ?
Z.B
(MemberOf=GruppeXYZ)Dann ginge das.
Gruß grexit
In der Anleitung ist nichts darüber zu finden. Zumindest bringt er beim
memberOf=CN=Scanneruser,OU=Berechtigungen,DC=domain,DC=de
oder
(memberOf=Scanneruser)
ebenfalls eine Fehlermeldung.
memberOf=CN=Scanneruser,OU=Berechtigungen,DC=domain,DC=de
oder
(memberOf=Scanneruser)
ebenfalls eine Fehlermeldung.
Wo hast Du das eingetragen? Doch hoffenlich nicht an der Bind-Root?
@122990 meint eine zusätzliche Einstellung. Den LDAP Filter eben. Falls Du da sowas nicht einstellen kannst, dann möglicherweise so:
Das Gerät muss doch vorher irgendwie angemeldet werden, damit es LDAP abfragen kann. Richtig? Falls ja, dann kann man über die Rechte dieses Benutzers eingrenzen, welche LDAP-Objekte er überhaupt lesen darf. Damit würde die Bind-Root wieder auf oberer Ebene festgelegt werden können. Müsste man ausprobieren.
@122990 meint eine zusätzliche Einstellung. Den LDAP Filter eben. Falls Du da sowas nicht einstellen kannst, dann möglicherweise so:
Das Gerät muss doch vorher irgendwie angemeldet werden, damit es LDAP abfragen kann. Richtig? Falls ja, dann kann man über die Rechte dieses Benutzers eingrenzen, welche LDAP-Objekte er überhaupt lesen darf. Damit würde die Bind-Root wieder auf oberer Ebene festgelegt werden können. Müsste man ausprobieren.
Aeh, ja, ich habe es ins BIND dazu geschrieben gehabt. Ein zusätzliches Feld für den Filter gibt es nicht.
Das zweitere kann nach meinem Verständnis nicht funktionieren. Der Scanner sucht den zu authentifizierenden Benutzer in einer OU, entweder ist er vorhanden oder nicht. Um erfolgreich zu sein muss der Benutzer in dieser OU sein. Ein Drucker würde es ebenfalls in einer OU suchen, natürlich in einer anderen, weil es ja unterschiedliche Rollen der Benutzer sein sollen. Um erfolgreich zu sein müsste der Benutzer dann auch in dieser OU existieren, im AD kann jeder Benutzer aber nur einmal existieren. Verschiedene Rechte würden nur dazu führen, dass der Benutzer sich nicht mehr authentifizieren kann. Sollte der Benutzer "alle" Rechte haben, kann er immer noch nicht in beiden OU's existieren.
Das zweitere kann nach meinem Verständnis nicht funktionieren. Der Scanner sucht den zu authentifizierenden Benutzer in einer OU, entweder ist er vorhanden oder nicht. Um erfolgreich zu sein muss der Benutzer in dieser OU sein. Ein Drucker würde es ebenfalls in einer OU suchen, natürlich in einer anderen, weil es ja unterschiedliche Rollen der Benutzer sein sollen. Um erfolgreich zu sein müsste der Benutzer dann auch in dieser OU existieren, im AD kann jeder Benutzer aber nur einmal existieren. Verschiedene Rechte würden nur dazu führen, dass der Benutzer sich nicht mehr authentifizieren kann. Sollte der Benutzer "alle" Rechte haben, kann er immer noch nicht in beiden OU's existieren.
???
In der Konfiguration zur Abfrage des LDAP hast Du doch sicher einen Benutzer angeben müssen? Dieser sollte a) nur ausschließlich für die Abfrage des LDAP verwendet werden und b) wird in seinen Rechten so eingeschränkt, dass er nur bestimmte Benutzer-Objekt im AD lesen kann. Dadurch könnte man die Bind-Root sogar auf Domänen-Ebene festlegen "DC=domain,DC=de". Oder fragt das Gerät nur genau diese eine Ebene ab, ohne Sub-OU's ?
In der Konfiguration zur Abfrage des LDAP hast Du doch sicher einen Benutzer angeben müssen? Dieser sollte a) nur ausschließlich für die Abfrage des LDAP verwendet werden und b) wird in seinen Rechten so eingeschränkt, dass er nur bestimmte Benutzer-Objekt im AD lesen kann. Dadurch könnte man die Bind-Root sogar auf Domänen-Ebene festlegen "DC=domain,DC=de". Oder fragt das Gerät nur genau diese eine Ebene ab, ohne Sub-OU's ?
Darf man denn mal erfahren was das für ein "ominöser" Scanner ist ?? Wir kennen ihn immer noch nicht 
Es ist ein Fujitsu N7100.
Ich weiss immer noch nicht wie das funktionieren soll mit den Berechtigungen. Ich gebe im Scanner den Suchpfad
OU=Berechtigungen,OU=Scanner,DC=domain,DC=de
und im Drucker
OU=Berechtigungen,OU=Drucker,DC=domain,DC=de
ein.
Wenn der User nicht scannen darf, wird ihm die Leseberechtigung für OU=Berechtigungen,OU=Scanner,DC=domain,DC=de
entzogen und der Scanner kann sich mit dem Benutzernamen nicht mehr authentifizieren.
Wenn der User nicht Drucken darf, wird ihm die Leseberechtigung für OU=Berechtigungen,OU=Drucker,DC=domain,DC=de
entzogen und der Drucker kann sich mit dem Benutzernamen nicht mehr authentifizieren.
Aber wenn der Benutzer beides dürfen soll, dann müsste dieser Benutzer doch in beiden Suchpfaden existieren, und das kann er ja nicht.
Ich weiss immer noch nicht wie das funktionieren soll mit den Berechtigungen. Ich gebe im Scanner den Suchpfad
OU=Berechtigungen,OU=Scanner,DC=domain,DC=de
und im Drucker
OU=Berechtigungen,OU=Drucker,DC=domain,DC=de
ein.
Wenn der User nicht scannen darf, wird ihm die Leseberechtigung für OU=Berechtigungen,OU=Scanner,DC=domain,DC=de
entzogen und der Scanner kann sich mit dem Benutzernamen nicht mehr authentifizieren.
Wenn der User nicht Drucken darf, wird ihm die Leseberechtigung für OU=Berechtigungen,OU=Drucker,DC=domain,DC=de
entzogen und der Drucker kann sich mit dem Benutzernamen nicht mehr authentifizieren.
Aber wenn der Benutzer beides dürfen soll, dann müsste dieser Benutzer doch in beiden Suchpfaden existieren, und das kann er ja nicht.
Boah. Harte Nuss ....
Was hat die pure Existenz eines Benutzers, die OU in welcher das Benutzerobjekt ist mit dessen Berechtigungen zu tun?
Nach meinem Kennnisstand funktioniert das doch so:
Der Drucker/Scanner fragt das AD/LDAP ab, was es dort für Benutzerobjekte gibt und bietet diese für das Login am Gerät an. Der Anwender wählt aus und gibt das zugehörige Passwort ein. Richtig? Ist das so bei Dir?
Falls ja: Damit das Gerät (nicht der Mensch!!!!) diese Objekte abgfragen und zur Auswahl anbieten kann, muss man ihm sagen, welchen Server er abfragen soll und was der Basis-Container für die Abfrage ist. Und mit welchem Benutzer sich das Gerät (nicht der Mensch !!) am LDAP anmelden soll, um die Benutzerobjekte abzufragen. Bis hier her: Ist das so bei Dir?
Falls auch ja: Wenn man also einschränken will, welche Benutzerkonten das Gerät überhaupt zur Auswahl anbietet kann, dann muss man die Berechtigungen des Kontos, welches das Gerät zur Abfrage des AD benutzt, einschränken. Und zwar so, dass es nur bestimmte Konten überhaupt findet.
Was hat die pure Existenz eines Benutzers, die OU in welcher das Benutzerobjekt ist mit dessen Berechtigungen zu tun?
Nach meinem Kennnisstand funktioniert das doch so:
Der Drucker/Scanner fragt das AD/LDAP ab, was es dort für Benutzerobjekte gibt und bietet diese für das Login am Gerät an. Der Anwender wählt aus und gibt das zugehörige Passwort ein. Richtig? Ist das so bei Dir?
Falls ja: Damit das Gerät (nicht der Mensch!!!!) diese Objekte abgfragen und zur Auswahl anbieten kann, muss man ihm sagen, welchen Server er abfragen soll und was der Basis-Container für die Abfrage ist. Und mit welchem Benutzer sich das Gerät (nicht der Mensch !!) am LDAP anmelden soll, um die Benutzerobjekte abzufragen. Bis hier her: Ist das so bei Dir?
Falls auch ja: Wenn man also einschränken will, welche Benutzerkonten das Gerät überhaupt zur Auswahl anbietet kann, dann muss man die Berechtigungen des Kontos, welches das Gerät zur Abfrage des AD benutzt, einschränken. Und zwar so, dass es nur bestimmte Konten überhaupt findet.
Handbuch Seite 113, es muss ein Konto angeben werden mit dem sich der Scanner am AD authentifiziert, also so wie @emeriks jetzt mehrfach gesagt hat, die Berechtigungen im AD so setzen das der Account welchen der Scanner nutzt nur auf bestimmte Container/Objekte Lesezugriff hat.
Ich weiss, harte Nuss, ich versuche ja durchzusteigen, aber ich sehe den Wald vor lauter Bäumen noch nicht :c(
Die Pure Existenz habe ich als pflicht angenommen, weil der Scanner immer versucht den Benutzer in der Suchbasis zu finden.
Die Suchbasis heisst im Moment: OU=Buero 1,DC=domain,DC=de
Der Benutzer gibt im Login Fenster seinen Benutzernamen und das Passwort ein, und der Scanner versucht dort diesen Benutzernamen zu finden. Wenn der Benutzername existiert, war die Anmeldung erfolgreich. Wenn er dort nicht existiert, gibt es eine Fehlermeldung. Das konnte ich schon soweit austesten. Das "Gerät" selbst hat keine Credentials gespeichert, mit dem er das Verzeichnis durchsuchen darf, die Abfrage passiert immer mit dem "Benutzer" selbst. Man kann auch keine Credentials dafür eingeben. Wenn als LDAP Servertyp "Active Directory" eingegeben wurde, fehlen die Felder zur Speicherung von Credientials.
Die Methode dem Benutzer die Suchbasis unsichtbar zu machen (Leserechte entziehen) wäre schon erfolreich, wenn es darum geht das Gerät zu "verbieten".
Nur wie müsste die Suchbasis lauten, wenn es darum geht das Gerät zu erlauben? Egal, was ich ihm als Suchbasis eingebe, er versucht immer dort den Benutzer zu finden.
Die Pure Existenz habe ich als pflicht angenommen, weil der Scanner immer versucht den Benutzer in der Suchbasis zu finden.
Die Suchbasis heisst im Moment: OU=Buero 1,DC=domain,DC=de
Der Benutzer gibt im Login Fenster seinen Benutzernamen und das Passwort ein, und der Scanner versucht dort diesen Benutzernamen zu finden. Wenn der Benutzername existiert, war die Anmeldung erfolgreich. Wenn er dort nicht existiert, gibt es eine Fehlermeldung. Das konnte ich schon soweit austesten. Das "Gerät" selbst hat keine Credentials gespeichert, mit dem er das Verzeichnis durchsuchen darf, die Abfrage passiert immer mit dem "Benutzer" selbst. Man kann auch keine Credentials dafür eingeben. Wenn als LDAP Servertyp "Active Directory" eingegeben wurde, fehlen die Felder zur Speicherung von Credientials.
Die Methode dem Benutzer die Suchbasis unsichtbar zu machen (Leserechte entziehen) wäre schon erfolreich, wenn es darum geht das Gerät zu "verbieten".
Nur wie müsste die Suchbasis lauten, wenn es darum geht das Gerät zu erlauben? Egal, was ich ihm als Suchbasis eingebe, er versucht immer dort den Benutzer zu finden.
Zitat von @89371:
Man kann auch keine Credentials dafür eingeben. Wenn als LDAP Servertyp "Active Directory" eingegeben wurde, fehlen die Felder zur Speicherung von Credientials.
Steht im Handbuch aber anders (Seite 113)Man kann auch keine Credentials dafür eingeben. Wenn als LDAP Servertyp "Active Directory" eingegeben wurde, fehlen die Felder zur Speicherung von Credientials.
- For [LDAP Server Access Authorization], enter an authorized user name an password when searching for users to be logged in to the LDAP server.
- For [LDAP Server Access Authorization], enter the authentification information for ActiveDirectory
Die Methode dem Benutzer die Suchbasis unsichtbar zu machen (Leserechte entziehen) wäre schon erfolreich, wenn es darum geht das Gerät zu "verbieten".
Nö, alles was der User sehen kann sieht er was er nicht sehen soll sieht er nicht ... Schon mal was von Delegation of Rights gehört ?
Du hast jedoch gerde folgende Einstellung vorgelesen:
"When [Other LDAP Server] is selected for [Server Type]:"
Meine Server Type heisst "Active Directory" und dann sieht die Maske aus wie auf dem Bild darüber in der Anleitung - also keine Ceredentials zum hinterlegen.
Ich bin trotzdem mal Deinem Vorschlag gefolgt und habe testweise mal auf "other LDAP Server" gestellt und dann konnte ich den Administrator dort eintragen und abspeichern. Das Ergebnis war dass nach wie vor der Benutzer im Pfad OU=Buero 1,DC=domain,DC=de gesucht wurde. Es kam auf das gleiche raus: Wenn er dort nicht existiert, gibt es eine Fehlermeldung. Wenn er dort existiert, ist die authentifizierung erfolgreich. Es ist nun also noch schlimmer geworden, da der Administrator immer alle Leseberechtigungen hat und damit dem user keine Leseberechtigung weg genommen werden kann...
"When [Other LDAP Server] is selected for [Server Type]:"
Meine Server Type heisst "Active Directory" und dann sieht die Maske aus wie auf dem Bild darüber in der Anleitung - also keine Ceredentials zum hinterlegen.
Ich bin trotzdem mal Deinem Vorschlag gefolgt und habe testweise mal auf "other LDAP Server" gestellt und dann konnte ich den Administrator dort eintragen und abspeichern. Das Ergebnis war dass nach wie vor der Benutzer im Pfad OU=Buero 1,DC=domain,DC=de gesucht wurde. Es kam auf das gleiche raus: Wenn er dort nicht existiert, gibt es eine Fehlermeldung. Wenn er dort existiert, ist die authentifizierung erfolgreich. Es ist nun also noch schlimmer geworden, da der Administrator immer alle Leseberechtigungen hat und damit dem user keine Leseberechtigung weg genommen werden kann...
Es ist nun also noch schlimmer geworden, da der Administrator immer alle Leseberechtigungen hat
und damit dem user keine Leseberechtigung weg genommen werden kann...
Och mönsch das ist echt schwer mit dir, wir haben doch nun bereits mehrfach gesagt das du dem User den du dort im Scanner als Abfrageuser einträgst im AD explitzit nur die Rechte auf die Objekte gibst die er sehen soll. Das der Admin alles sieht ist ja logisch !und damit dem user keine Leseberechtigung weg genommen werden kann...
Lege also am besten genau für diese Aufgabe einen neuen Service-User an dem du nur die nötigen Rechte im AD vergibst, so dass dieser nur die Accounts sieht welche Zugriff auf dem Scanner bekommen sollen.
Und das machst du nicht mit dem LDAP-Pfad sondern über die explizite Zuweisung der ACLs im AD (z.B. mit ADSIEdit oder Delegation of Rights, etc. pp)
Die Delegation von Berechtigungen
Ansonsten solltest du deine OU-Struktur nochmal überdenken.
Ahhh, jetzt ist der Groschen gefallen - ach, was sage ich, der Gulli Deckel...
Es gibt einen Service user, dieser sieht nur die Chefs in der OU Struktur. Ein Chef kann sich damit mit seinem Namen anmelden.
Nachdem im Dokumentenscanner unter LDAP Server Type "Active Directory" keine Credentials für den Service User hinterlegt werden können, muss ich den "Server Type" auf "Other LDAP Server" stellen. Jetzt klappt es. Ich konnte diesem Service-User bereits bereiche aussperren oder erteilen.
Vielen lieben Dank für Eure Geduld :c)
Es gibt einen Service user, dieser sieht nur die Chefs in der OU Struktur. Ein Chef kann sich damit mit seinem Namen anmelden.
Nachdem im Dokumentenscanner unter LDAP Server Type "Active Directory" keine Credentials für den Service User hinterlegt werden können, muss ich den "Server Type" auf "Other LDAP Server" stellen. Jetzt klappt es. Ich konnte diesem Service-User bereits bereiche aussperren oder erteilen.
Vielen lieben Dank für Eure Geduld :c)
jeht doch! 
