LDAP LDAP Server als Benutzerverwaltung für Win 7 Clients - meine Version zur Diskussion

[Galileo]

Hallo in die Runde!

Seit einigen Wochen bin ich semi-professioneller Synology DS-Nutzer und seit ein paar Tagen hier angemeldet. Mein aktuelles Thema: Ich will den LDAP-Server auf der DS1513+ nutzen um die User unserer beiden DS sowie der diversen Windows-Rechner zentral zu verwalten.

Ich will das auf Basis der DS machen weil mir der Aufwand zur Einrichtung und Pflege eines Windows Domain Controllers zu hoch ist, ich bin kein Administrator, ich will mit den Rechnern nur arbeiten und dabei nebenbei meinen Spaß haben.

Als LDAP-Client auf den Windows-Rechnern bin ich durch dieses Forum auf pGina gekommen: pgina.org. Eine erste funktionierende Version habe ich jetzt auf die Beine gestellt, dabei haben mir hier im Forum gefundene Informationen vielfach weitergeholfen, vielen Dank an dieser Stelle an alle Schreiber!

Meinen momentanen Stand möchte ich hier aus zwei Gründen dokumentieren:

1.) Erstens hoffe ich auf eure Anregungen und Verbesserungstipps, insbesondere werden meine Anforderungen leider noch nicht komplett erfüllt, und meine Lösung ist bestimmt auch noch ausbaufähig.
2.) Zweitens will ich Leuten wir mir die das Thema ganz neu angehen eine konsistente Dokumentation einer funktionierenden Konfiguration zur Verfügung stellen.

Es gibt hier zwar schon diverse Anleitungen, allerdings habe ich noch keine gefunden in der beide Seiten, also Synology LDAP-Server und Windows pGina komplett und konsistent beschrieben wurden.

 

[Galileo]

Nun zunächst zu meinen Zielen und Anforderungen:

Ausgangslage:

Wir haben knapp zehn Windows Rechner (Workstations und Notebooks) und neuerdings zwei DS und sind etwa fünf Personen. Manche Notebooks sind persönlich zugeordnet, andere wiederum nicht, zum Beispiel weil sie Softwarelizenzen haben die auf ein System begrenzt sind, oder weil sie Installationen haben mit denen man den persönlichen Rechner nicht vollstopfen will usw. Teils gibt es dann pro Rechner auch noch mehrere wahlweise bootfähige Betriebssysteme, zum Beispiel eines zum Arbeiten und eines zum Testen, oder einmal Win 7 und einmal XP usw.

Nun hat jeder Rechner bzw. sogar jedes Betriebssystem natürlich seinen eigenen Satz von Usern und Passwörtern (als "User" bezeichne ich im Folgenden nicht Personen sondern Benutzerkonten) und die laufen natürlich auseinander, und es ist keiner da der das irgendwie rechnerübergreifend plant, pflegt oder konsistent hält. Passwörter werden kaum einmal geändert, weil man es an jedem Rechner einzeln machen müßte, und es wird der "Einfachheit" halber oft als Administrator gearbeitet statt diese Rechte nur im Bedarfsfall anzunehmen.


Ziel:

Im Grunde will ich eigentlich eine Benutzerverwaltung ähnlich einer Windows-Domain haben:

Ich will zentral am LDAP-Server der DS1513+ alle User aller Rechner verwalten, einzige Ausnahme sollen pro Rechner zwei lokale Admin-Konten sein die nur in Notfällen zu benutzen sind falls es ein Problem mit sämtlichen LDAP-Konten geben sollte o.ä.

Eine zweite Synology DS arbeitet als LDAP-Client am LDAP-Server der DS1513+, verbunden übers interne Netz.

Alle Windows-Rechner werden mit pGina zu Clients des DS1513+ LDAP-Servers und beziehen von dort die Benutzer-Anmelde-Informationen. Nicht jeder LDAP-User soll auf jeden Windows-Client-Rechner zugreifen können, vielmehr soll im LDAP-Server gesteuert werden welcher User auf welchen Windows-Client-Rechner als Admin, User, Gast, (ggf. Sonstiges Gruppenmitglied) oder garnicht zugreifen kann. Dies soll auch geändert werden können.

Die Windows-Clients sollen sowohl übers interne Netz als auch über Internet Verbindung zum LDAP-Server aufbauen können.

Sind die Clients offline, dann soll pro User der letzte vom LDAP-Server übernommene Stand aktiv bleiben.


Abstriche:

Soweit im Groben die Anforderungen. Ganz erfüllt werden sie nicht, insbesondere ist es in meiner Lösung nicht möglich, einen User zentral zu löschen, bzw. kann man ihn natürlich löschen aber lokal auf den Clients bleibt er dann bestehen. Aus den einzelnen Gruppen (Benutzer, Administratoren) kann ich ihn zwar vom Server aus gesteuert löschen, im Online-Betrieb hat er auch keinen Zugriff mehr, aber im Offline-Betrieb bleibt er mindestens als Gastuser erhalten und aktiv.

Nun kommt das Löschen von Usern nicht oft vor, aber wenn doch dann muss ich ihn eben manuell an allen Windows Clients einzeln ebenfalls löschen. Sollte es hier eine bessere Lösung geben, dann würde mich das sehr interessieren.

 

[Galileo]

Vorab noch eine Warnung vor pGina:

Vorsicht! pGina ist kein Spielzeug, es übernimmt komplett den Zugang zum System! Das bedeutet: Ein Fehler kann dazu führen, dass das System keine Möglichkeit mehr bietet, sich einzuloggen, d.h. in dem Fall kann es tot sein, oder der Zugang als Admin kann blockiert sein, was fast genauso schlecht ist. Es gibt im web diverse Berichte in denen derlei Dinge tatsächlich passiert sind.

Mir ist es z.B. passiert, dass plötzlich mein lokales Konto "Administrator" nicht mehr funktioiert hat - pGina hat das Passwort gescrambelt, weil es das war was ich konfiguriert hatte, und das wars - zum Glück hatte ich weitere lokale Administrator-Konten auf Lager. Sofern man also im Local Machine Plugin mit Scramble experimentiert sollte man jedenfalls hier seine lokalen Adminkonten schützen:

Die sicherste Lösung ist aber natürlich vor der Installation von pGina eine komplette Systemsicherung herzustellen.

Mindestens sollte man eine Notfall-Disk zum Rücksetzen des Administrator-Passworts herstellen.

 

[Galileo]

Installation des LDAP-Servers


Directory Server aus dem Paketzentrum laden und starten, folgende Einstellungen:

Die FQDN habe ich an dieser Stelle komplett willkürlich gewählt, also frei erfunden. Man könnte hier natürlich die DDNS-Internetadresse der Station benutzen (subdomain.topdomain.com oder so), ich wüßte aber momentan nicht was das für Vorteile haben sollte. Vielleicht kann jemand dazu etwas sagen?

Das Passwort ist an dieser Stelle frei erfunden und wird später identisch auch in pGina unter Windows sowie an der zweiten DS im Verzeichnisdienst (LDAP-Client) angegeben.



Dann habe ich beispielhaft 3 User angelegt:

Der User ldapwinuser ist wie folgt konfiguriert:

Durch die Gruppenmitgliedschaften werden seine Rechte festgelegt:

In dem Fall soll er allgemein auf den Windows-Systemen als User fungieren, allerdings soll er auf einem bestimmten W540 Notebook gleichzeitig Administrator sein. Die Auswertung dieser Eingruppierung erfolgt dann später auf jedem Windows-Client individuell in der pGina-Konfiguration.

Mehr braucht der User an dieser Stelle nicht:

 

[Galileo]

Beim User ldapwinadmin ist beispielhaft eine andere Gruppenzuordnung gewählt:

Er soll sowohl auf den DS als auch unter Windows überall als Administrator fungieren.


Und hier noch beispielhaft der User ldapwinguest:

Dieser User hat unter Windows lediglich Zugriff zu den Workstations, und dort auch nur als Gastuser. Auf allen anderen Windows-Rechnern wird er abgelehnt.

Da ich auf meinen beiden DS den LDAP-Client aktiviert und mit diesem LDAP-Server verbunden habe, hat allerdings auch dieser User Zugriff zu den DS. Was er dort dann genau darf, außer sein Passwort zu ändern, hängt natürlich von der weiteren Konfiguration der DS ab.


Aktivierung des LDAP-Client lokal auf der DS1513 im Verzeichnisdienst:

Die Werte sind Default-Werte, auch die Base-DN wird beim Anklicken vom LDAP-Server bezogen und korrekt vorgeschlagen.


Auf der zweiten DS im internen Netz sieht die Verknüpfung mit dem LDAP-Server der 1513 so aus:

Die LDAP-Server-Adresse ist die interne IP der DS1513+, der DHCP-Server im internen Netz (mein Internet-Router) kennt ihre physikalische MAC-Adresse und weist ihr immer diese IP zu. Da die Daten ja übertragen werden, wenn auch nur intern, habe ich hier Verschlüsselung aktiviert.

Beim Übernehmen habe ich an der zweiten DS die Bind-DN und das Passwort aus dem LDAP-Server der 1513 eingegeben (siehe Beitrag 4 erstes Bild):

 

[Galileo]

Firewall-Einstellungen der DS1513 für den LDAP-Server:

Damit der LDAP-Server der DS1513 auch erreichbar ist muss

- entweder für unverschlüsselten Betrieb das Port 389 offen sein
- oder für verschlüsselten Betrieb das Port 636 offen sein

Sofern der Server nicht nur übers interne Netz sondern auch aus dem Internet erreichbar sein soll, ist diese Freigabe natürlich ggf. auch am Router zu bedenken.

Bei mir ist derzeit die Firewall der DS1513 komplett offen, erstens weil ich fleißig am Testen und konfigurieren bin, und zweitens weil mein Router eine aktive Firewall besitzt. Wenn ich mit der Einrichtung meines Systems fertig bin, werde ich dann auch an der 1513 noch alles zu machen was ich nicht brauche.

Momentan sieht die Firewall der DS1513 aber einfach so aus:

("Bond 1" steht hier dafür dass ich die 4 Gigabit-LAN-Ports mit LACP verbunden habe, sie hängen alle parallel an meinem Switch, aber das ist eine andere Baustelle.)


Damit die Windows-Clients sich über Internet verbinden können habe ich also im Router (Fritz-Box) folgende Freigabe eingerichtet:

636 bedeutet also: Verschlüsselter Betrieb.

 

[Galileo]

Windows-Clients mit pGina:

Ich habe die neuste stabile pGina Version 3.1.8.0 installiert.

Bitte auch die Online-Dokumentation unter http://pgina.org/docs/v3.1/index.html hinzu ziehen.

Unter "General" habe ich weiter nichts verändert:

Allerdings zeigten nach der ersten Installation die beiden Felder unter "Credential Provider/GINA Status" noch ein rotes "No". Ohne lang zu suchen habe ich einfach die Installation (ohne vorherige De-Installation) wiederholt, dann war es ok.


Plugin Selection:

In der Plugin Selection gibt es nun, je nachdem was man genau machen will, verschiedene Optionen. Da ich aber Benutzer nicht nur einfach authentifizieren sondern ihnen auch auf Grund von LDAP-Gruppenzugehörigkeit lokale Rechte einräumen will habe ich abweichend von der Default-Konfiguration für das LDAP-Plugin alle 3 Stages aktiviert, so dass insgesamt die Plugins LDAP und Local Machine in allen 3 Stages aktiv sind.

 

[Galileo]

gGina Plugin LDAP

LDAP habe ich wie folgt konfiguriert:

Unter LDAP Hosts habe ich sowohl die interne IP als auch die Internet-Adresse (DDNS) der DS1513 angegeben, "subdomain.topdomain.com" ist natürlich nur beispielhaft. Die beiden Angaben sind durch ein Leerzeichen zu trennen.

Am Group DN Pattern und am User DN Pattern mußte ich herum laborieren bis es funktioniert hat (ich meine ich mußte ein "ou" durch "cn" ersetzen oder so ähnlich), und der Teil "dc=DS1513, dc=local" entstammt natürlich der BASE DN des LDAP-Servers, siehe Beitrag 4 Bild 1.

Ferner habe ich Verschlüsselung SSL angeklickt und gehe dem entsprechend über das Port 636, siehe auch Firewall Beitrag 6.

Unter LDAP-Plugin, Authorization folgen nun für den individuellen Windows-Client die Einstellungen, welche LDAP-User zu diesem Rechner grundsätzlich Zugriff bekommen sollen, was ja über die Gruppenzugehörigkeit im LDAP-Server geregelt wird:

In meinem Fall handelt sich um das W540 Notebook, und in meinem Konzept sollen hier alle Zugriff bekommen, denen ich im Server entweder individuell Zugang zu diesem Notebook oder allgemeinen Zugriff auf alle Windows-Clients eingeräumt habe. (Über die Nutzungsrechte ist bis dahin noch nichts entschieden, dies folgt im nächsten Schritt.)

Bei der Option "Allow when server is unreachable" muss man sich leider zwischen 2 Problemen entscheiden - wenn da jemand eine bessere Lösung kennt würde mich das sehr interessieren:

Klickt man die Option nicht an, dann bedeutet das, dass User-Anmeldungen generell nur funktionieren wenn Verbindung zum LDAP-Server besteht. Das macht zumindest für ein mobiles Notebook natürlich keinen Sinn.

Also muss man die Option wohl anklicken. Das bedeutet dann aber dass der User im Offline-Betrieb zum Client auch dann Zugang bekommt, wenn sein Zugriff (in Form der Gruppenzugehörigkeit) im Server wieder gelöscht wurde, dies allerdings nur wenn er früher einmal Zugang hatte und daher lokal gespeichert ist und von der Local Machine authetifiziert werden kann.

In einem solchen Fall muss man also manuell hergehen und den User vom Client manuell löschen. Gesucht ist also eine Möglichkeit, wie ein einmal lokal gespeicherter User vom Server aus gesteuert entweder wieder entfernt oder wenigstens deaktiviert werden kann. (Mit Passwort Scramble habe ich laboriert, das brachte dann aber auch wieder mit sich dass kein Offline-Betrieb möglich war.

In dem Zusammenhang sei angemerkt, dass unter Win 7 gespeicherte Benutzer in der einfachen Benutzerverwaltung (unter Systemsteuerung / Benutzerkonten) nur sichtbar sind wenn sie Mitglied bestimmter Gruppen wie "Benutzer" oder "Administrator" sind. Sind sie nur Gastuser, dann sieht man sie nur in der erweiterten Benutzerverwaltung unter Systemsteuerung / System und Sicherheit / Verwaltung / Computerverwaltung / Lokale Benutzer und Gruppen / Benutzer, man muss sich also dort hin begeben wenn man sie finden und löschen will.


LDAP-Gateway:

Im LDAP-Gateway folgt nun schließlich noch die Zuweisung von Rechten durch Zuordnung zu den entsprechenden lokalen Gruppen. Auf diesem speziellen Rechner werden nun entsprechend meiner Struktur die User zum Benutzer bzw. zum Admin erhoben, für die das entweder allgemein für alle Windows-Rechner oder eben speziell für dieses Notebook vorgegeben ist.

Diese User sind dann auch in der einfachen Benutzerverwaltung (Systemsteuerung / Benutzerverwaltung) als ganz normale lokale User bzw. Administratoren sichtbar.

 

[Galileo]

Plugin Local Machine:

Das Plugin Local Machine habe ich wie folgt konfiguriert:

Option: Always authenticate local users:

Dieses Haken habe ich entfernt. Damit habe ich erreicht, dass bei Authentifizierung durch LDAP keine zusätzliche Authentifizierung durch die LM erfolgt. Dies hat den Grund, dass ich nicht will, dass die LM dem User von vorn herein die lokalen Gruppen zuordnet, die derzeit gespeichert sind. Vielmehr will ich, dass die Zuordnung zu den lokalen Gruppen entsprechend der aktuellen Zuordnung am Server neu aufgebaut werden soll, sofern der LDAP-Server erreichbar ist.

Nur wenn also LDAP keine Authetifizierung liefert, also primär im Offline-Betrieb, erfolgt die Zuordnung zu den lokalen Gruppen entsprechend dem zuletzt gespeicherten Stand.

Auch hier hat mein Konzept leider einen Schönheitsfehler, den ich gerne beseitigen würde: Ist ein User lokal einmal als Benutzer oder Administrator gespeichert, und wird dann im Server diesem Benutzer der Zugang zu diesem Rechner komplett gesperrt, dann bleibt er im Offline-Betrieb nicht nur als Gastuser erhalten (wie oben beschrieben), sondern es bleiben ihm auch die zuletzt zugeordneten Gruppen erhalten. Ich kann ihm die lokal gespeicherte Zuordnung zu den Benutzern oder Administratoren also vom Server aus nur entziehen, indem ich ihm den Gastuser-Status belasse. Ansonsten muss ich wie gesagt eben lokal eingreifen.


Option: Mirror groups from local user:

Hier geht es genau um die selbe Sache, nämlich ob die lokal bisher zugeordneten Gruppen beim Login auf jeden Fall übernommen werden oder nicht. Da ich das nicht will ist es ausgeklickt. Wäre es angeklickt, dann würden die Gruppen auch in dem Fall übernommen, wenn die Authentifizierung nicht durch die LM sondern durch LDAP erfolgt.


Option: Authorize all authenticated users:

Dies habe ich ebenfalls ausgeklickt. Wäre es angeklickt, dann würde die LM auch User authorisieren, die von LDAP authentifiziert wurden, dies zu entscheiden ist aber Sache von LDAP, denn nicht alle von LDAP authentifizierten User erhalten auch Zugriff (sondern nur die, die auch zu einer freigegebenen Gruppen gehören).


Optionen: Require local administrator group membership / Require membership in one of the following local groups: Damit konnte ich bisher in meinem Kontext nichts sinnvolles anfangen. Ich will die Gruppenzugehörigkeit ja bei jedem Login neu definieren.


Option: Failure to create or join local groups should prevent login: Kann ich nichts mit anfangen, lasse ich mal weg, ist vermutlich egal.

Auch mit den restlichen Optionen kann ich für meinen Zweck derzeit nichts anfangen:


Option: "Remove account and profile after logout when account does not exist prior to logon"

läuft darauf hinaus dass die LDAP-User lokal nur temporär angelegt werden.


Option: Scramble Password after logout

läuft darauf hinaus, dass der Zugriff auf den Client ausschließlich auf LDAP-User reduziert wird: Da allen Usern beim Logout das Passwort zerstört wird kann sich außer über LDAP keiner mehr erneut einloggen. Ferner kann man sich nur noch mit Zugriff auf den LDAP-Server einloggen, offline geht nicht mehr sobald das Passwort einmal beim Logout gescrambelt wurde. Wenn man damit experimentiert sollte man die lokalen (Not-)Admins als Ausnahmen definieren, deren Passwörter nie gescrambelt werden sollen.


Option: Only scramble when LocalMachine authentication fails or does not execute

schränkt das Scrambeln ein: Die lokal ursprünglich vorhandenen User sind ausgenommen, denn die können durch die LM authentifiziert werden. Allerdings: Sollte einer dieser User auch durch LDAP authentifiziert werden, dann fällt er aus der Ausnahmegruppe heraus, weil ja dann die LM-Authentifizierung nicht ausgeführt wird (es sei denn die Option "Always authenticate local users" wäre an, dann würde immer die LM-Authetifizierung erfolgen und die lokalen User sollten vor dem Scrambeln geschützt sein).

Zu diesen Scrambel-Optionen muss man noch sagen, dass das von einem separaten Prozess und mit zeitlicher Verzögerung ausgeführt wird. Man muss also beim Testen - sowohl mit echtem Einloggen als auch unter dem Reiter "Simulation" - immer genug Zeit vergehen lassen bevor man einen neuen Versuch startet, ansonsten wird das Ergebnis verfälscht, weil der Scramble noch nicht zugeschlagen hat.

Das bedeutet aber andererseits auch, dass das Scrambeln nicht stattfinden kann, wenn es zum Beispiel einen Stromausfall gibt. Ob das dann nach dem Neutstart noch nachgeholt wird weiß ich nicht.




Option: Mandatory Groups:

Fügt alle authorisierten User bestimmten Gruppen immer zu - macht in meinem Konzept bisher keinen Sinn.

 

[Galileo]

Plugin Order:

Ich habe immer LDAP zuerst und dann LM angeordnet. Die Reihenfolge ist durchaus wichtig, das ganze Konzept beruht darauf. Ob es hier andere Optionen gibt oder welche Möglichkeiten die eröffnen würden habe ich mir bisher keine Gedanken gemacht.


Die Simulation machen wir später, zuerst noch ein Blick auf die

Credential Provider Options:

Hier habe ich nichts verändert, weil ich mich damit noch nicht beschäftigt habe, obwohl einige Tutorials angeben man müßte da irgendas ankreuzen, warum ist mir nicht klar. Wenn mir jemand das erklären kann wäre ich dankbar.

Nicht zuletzt die unten stehende Warnung hat mich vom Experimentieren in dieser Richtung abgehalten, ich habe keine Lust meine letzte Systemsicherung zu reaktivieren.


Die Konfiguration ist damit fertig, fangen wir an zu testen:

 

[Galileo]

Simulation:

Gehen wir davon aus, unsere 3 User ldapwinguest, ldapwinuser und ldapwinadmin waren am Notebook W540 noch nie angemeldet.

Beginnen wir mit dem ldapwinadmin. Der ist für alle Systeme als Admin vorgesehen, siehe Beitrag 5 Bild 1.

Erster Versuch: Wie man rechts unten im Netzwerkstatus sehen kann sind wir offline und versuchen eine Anmeldung:

Erwartungsgemäß geht die Anmeldung nicht, das Notebook kennt den User ja noch nicht.


Gehen wir nun online, es folgt der 2. Versuch:

Der LDAP-Server ist erreichbar, also wird der User authentifiziert.
Die LM-Authetifizierung entfällt, da der User bereits durch LDAP authetifiziert ist (siehe Option "Always authenticate local users", die ist aus).

Auch die LDAP-Authorisierung klappt, auf Grund der Gruppenmitgliedschaft "win-admin", somit hat die LocalMachine nichts gegen die Authorisierung einzuwenden.

Im Gateway erfolgt dann die Zuordnung zu den Administratoren, weil in Beitrag 8 Bild 3 die dritte Regel zutrifft: Der User ist als "win-admin" vorgesehen.

Nunmehr ist der User ldapwinadmin als lokaler Administrator genauso installiert wie andere Administratoren auch und kann auch offline angemeldet werden:

LDAP authentifiziert nicht, weil der Server nicht erreichbar ist. Dafür authentifiziert die LM auf Grund des lokal gespeicherten Users, und wenn das passiert werden bekanntlich seine lokalen Gruppen übernommen (Beitrag 9).

Auf Grund der Option "Allow when Server is unreachable" (Beitrag 8 Bild 2) authorisiert LDAP auch den durch LM authentifizierten User. Mangels Verbindung werden zwar keine Gruppen hinzugefügt, das ist aber auch nicht nötig, da bei der LM-Authetifizierung bereits geschehen.

 

[Galileo]

Melden wir nun den User ldapwinuser an, dass es offline bei ersten Mal nicht geht ist trivial,

beginnen wir gleich online:

Die Authentifizierung via LDAP klappt, also entfällt die LM-Authentifizierung.

Bei der LDAP-Authorisierung gibt es sogar zwei zutreffende Regeln, die erste greift: ldapwinuser gehört zur Gruppe "win-user".
Im Gateway werden hier allerdings zwei Gruppen hinzugefügt: Allgemein unter Windows ist ldapwinuser nur Benutzer, am W540-Notebook hatten wir ihn aber als Admin vorgesehen, siehe Beitrag 4 Bild 4, somit wird er zu beiden Gruppen hinzugefügt, wobei die Zugehörigkeit zu den Benutzern nicht stört, der ldapwinuser ist Administrator.

Machen wir die Anmeldung nicht nur simuliert sondern tatsächlich, dann bestätigt sich das in der Benutzerverwaltung:

Versuchen wir nun einmal, dem ldapwinuser die Admin-Rechte für das Notebook zu entziehen: Auf der DS1513 im LDAP-Server wird das Häkchen gelöscht und der Status gespeichert:

In der simulierten Anmeldung sieht es daraufhin so aus:

In der realen Anmeldung bestätigt sich dieses:

ldapwinadmin ist nur noch Benutzer statt Administrator.

 

[Galileo]

Versuchen wir nun, dem ldapwinuser den Zugriff auf dieses Notebook komplett zu entziehen. Dazu muss ich ihn aus der Gruppe win-user heraus nehmen. Wenn er an anderen Rechnern Rechte haben soll, dann muss ich diese eben einzeln vergeben.

Beispielsweise sieht das dann so aus:

Jetzt ist er an anderen Rechnern Admin, sollte aber auf das W540 Notebook keinen Zugriff mehr haben.

Simulation online:

Das ist das erwünschte Ergebnis: LDAP authetifiziert den User, also unterbleibt die LM-Authetifizierung. LDAP authorisiert aber nicht, weil ldapwinuser zu keiner für diesen Rechner relevanten Gruppe gehört. Und wenn LDAP nicht authorisiert, dann authorisiert LM auch nicht und das Login wird abgelehnt.

So weit so gut. Der User ist aber lokal noch drin. Versuchen wir es nun offline:

Dieses Ergebnis ist erklärlich, aber eigentlich nicht erwünscht: Hier stehen wir an dem mehrfach erwähnten Problem: Ist der User einmal drin, dann kann ich ihn vom Server aus von diesem Rechner nicht mehr komplett ausschließen, ich muss ihn manuell lokal am Client löschen.

Solange es aber nicht um den kompletten Ausschluss sondern nur um den Wechsel von Rechten an dem Client geht funktioniert alles wie gewünscht:

 

[Galileo]

Machen wir zur Probe den ldapwinuser am W540 zum Gast:

Simulation online:

Funktioniert.

Simulation Offline:

Funktioniert erwartungsgemäß auch.

Bei realer Anmeldung sieht das dann so aus:

Erwartungsgemäß ist ldapwinuser nun Gastuser.

Anmerkung: Wie schon gesagt: Für andere User bzw. Admins ist ein Gastuser in der einfachen Benutzerverwaltung nicht mehr sichtbar, dazu muss man die erweiterte Benutzerverwaltung in der Computerverwaltung aufsuchen. Auch am Willkommensbildschirm ist er nicht sichtbar, er kann sich aber am pGina-Symbol trotzdem anmelden.

Den Test von ldapwinguest können wir uns nun eigentlich sparen, der ist ja an diesem Computer sowieso nicht freigegeben.

 

[Galileo]

Zusammenfassung:

Damit bin ich mit der Dokumentation meiner Lösung durch, hat etwas länger gedauert als ich geplant hatte, so ist das nun mal. Vielleicht können damit einige andere mit LDAP und pGina schneller zum Ziel kommen und pGina schneller verstehen als ich selbst. Für Rückfragen bin ich offen.

Cool wäre natürlich, wenn Anregungen und Verbesserungsvorschläge eingehen würden, obwohl ich denke, dass das nicht ganz einfach ist.

Möglicherweise habe ich aber auch selber bereits neue Ideen, diese die intensive Beschäftigung mit dem Thema im Rahmen dieser Doku hat mich selbst auch nochmals weiter gebracht.

Viel Spaß mit dem Thema!

 

[Daniel Albert]

Hallo,

spiele auch gerade mit PGina rum und bin soweit recht zufrieden. Einen Fehler habe ich noch. Wenn ein User über LDAP an einem PC angemeldet ist und nach 10 Minuten Leerlauf der Bildschirmschoner erscheint wird er ja nach dem Passwort gefragt.

Da bekomme ich folgende Fehlermeldung:

plugin did not provide a specific error message

Der Nutzer kann sich nicht mehr so einfach Anmelden.

hat jemand eine Idee?

Gruß Daniel

 

[Galileo]

Ich arbeite normal nicht mit Bildschirmschoner, habe es aber gerade mal ausprobiert:

Bei LDAP-Authentifizierung funktioniert bei mir auch die Freischaltung mit Passwort.

 

[Daniel Albert]

Hallo,

ok muss ich ausprobieren. Bei uns kommt wenn der Bildschirmschoner aktiv ist nur wie beim Windows die passwortabfrage von dem jeweiligen Nutzer der schon angemeldet war. Gebe ich dann das Pw ein kommt die besagte Fehlermeldung. Ich muss mir deinen Weg mal genau durchlesen. Ich sehe aber schon zu meinem Unterschiede.

Zum einen habe ich bei den Plugin LDAP nur Authentication angeklickt und Local Maschine Gateway und Authentication.

Unter Credential habe ich Passwortprovider angeklickt wobei dies mal jemand im Forum geschrieben hat,ob ich das wirklich benötige weiß ich nicht.

Gruß Daniel

 

[Galileo]

Bei uns kommt wenn der Bildschirmschoner aktiv ist nur wie beim Windows die passwortabfrage von dem jeweiligen Nutzer der schon angemeldet war.

Ja, das meine ich. Ist bei mir auch so. Passworteingabe funktioniert bei mir dann.

Du könntest ja mal das Log-File anschauen oder hier rein stellen.

Unter Credential habe ich Passwortprovider angeklickt wobei dies mal jemand im Forum geschrieben hat,ob ich das wirklich benötige weiß ich nicht.

Damit wird erreicht, dass man User und Pw nur noch über pGina eingeben kann, nicht mehr über Windows selber an pGina vorbei.

In meiner Konfiguration führt das dazu, dass bei online-Verbindung zum LDAP-Server keine Anmeldung mehr über lokale Nicht-LDAP-User möglich ist - sofern man denn welche hat. (Es sei denn sie sind lokale Admins, dann greift das "Local Admin Fallback", dann wird man gnädigerweise trotzdem reingelassen.)

 

[Daniel Albert]

Hallo,

danke für dein Feedback, dann passt das für mich mit Passwortprovider: Bei dem Problem mit dem Bildschirmschoner muss ich mir mal am Mittwoch die Logdatei besorgen.

Bald habe ich noch 2 Laptops im System denke da werde mich mal deinen Weg ausprobieren. Finde diesen nicht schlecht, aktuell brauche ich es noch nicht alles. Aber eine sehr gute Anleitung, endlich. Danke

Hier mal mein Feedback und noch 2-3 Fragen

Hallo,

Also bei uns ist si Ähnlich wie bei dir zumindest meine Vorstellung wie das System laufen sollte liegt deinem sehr nahe.
Einzige die Festlegung, dass sich nicht jeder auf jeden Pc anmelden kann weicht ab.

Bei Group DN Pattern habe ich nichts eingetragen, auch kein Passwort. Für was ist dieses nötig?

Authorization habe ich verstanden, da bei uns jeder auf jedem Rechner Zugriff haben sollte , brauche ich diesen Punkt nicht zu beachten, denke ich

Gateway, die Lokale Gruppenzuweisung für die Rechte habe ich nicht genutzt aber festgestellt, dass standard die User als Benutzer angemeldet werden. Für Admin nutze ich das lokale Profil. Ich denke das braucht man nur, wenn auch Nutzer als admin sich am PC anmelden sollten oder ??

Bei LM Konfig den Punkt "Always authenticate local users" verstehe ich nicht ganz. Hat dieser was mit dem Punkt weiter oben Gateway zu tun , sprich wenn man die Rechtsvergabe bei der Anmeldung nicht dem Standard überlassen will ?

Mit dem Scramble Pw verstehe ich nicht was damit gemeint ist. Wenn ein User sich an einem PC abmeldet, kann sich wer mit diesem Pw nochmals anmelden ?? Welchen Vorteil hat dies von der Sicherheit.


Das mit dem Gastzugang interessiert mich. Muss mal schauen ob ich das auch nur auf einem Pc zum laufen bekomme. Wir haben einen Gastrechner vielleicht wäre deine Idee dort einsetzbar.


Ein Problem habe ich noch und da hängt es am Verständnis.

Wir haben für unsere Branche viele kleine zusätzliche Programme die ich nicht auf jeden Rechner installieren möchte da diese nur sporadisch genutzt werden. Dafür habe ich den o.g. Gastrechner ebenfalls mit eingerichtet. Dort gibt es ein Benutzerkonto "Tarifrechner" Dieses ist für Remotedesktopverbindung freigegeben.

Ziel dahinter: Möchte jemand z.B. eines dieser besagten Tools nutzen meldet er sich über Terminal mit dem Konto Tarifrechner am Gastrechner an. Dann erscheint die Anmeldemaske von Pgina. Er sollte er seine normalen Nutzerdaten benutzten. Mit dem lokalen Adminkonto geht das aber versuche ich mich mit einem LDAP KOnto anzumelden, erscheint die Meldung, "Dieser Benutzer hat für diese Anmeldung nicht die Rechte oder so ähnlich" Bin jetzt leider nicht im Büro. Jetzt verstehe ich nicht an was das liegt.

Hast du eine Idee?

Hast du in diesem Bereich eine Schulung gemacht oder woher kommt das Fachwissen ?

Gruß Daniel