Windows Benutzerverwaltung mitverwenden

[ralfiii]

Hallo!

Wir haben eine Datenbank-Anwendung mit einer kleinen Benutzerverwaltung (Benutzername, Passwort, pro Benutzer ein paar anwendungsspezifische Rechte und Einstellungen. Weiters können Datensätze optional mit Benutzern verknüpft werden, so dass ein Benutzer wenn er will nur "seine" Daten sieht)

Nun möchten manche Kunden (meist Krankenhäuser) die Benutzer nicht bei uns und in ihrem Netzwerk einpflegen.
Soweit ich das verstehe ist oft ein Dummy-User an einem Rechner angemeldet. Wenn jetzt jemand unsere Software startet soll die SW optional einen Login-Dialog anzeigen. Dabei soll nicht der Anwendungskontext geändert werden, es geht hier primär um die Authentifizierung.

(Ein anderes Verhalten wäre wohl den aktuell benutzte Windows-User zu verwenden. Ich schätze das sollte recht einfach hinzukriegen sein, also konzentriere ich mich mal auf den komplizierteren Fall)

Ich hab mal kurz gegoogelt, da fliegen einem die Begriffe "Active Directory", "Kerberos", "LDAP" etc. nur so um die Ohren - hab davon leider keinen Schimmer davon.

Kann mir jemand mal einen Tip geben?

Und dann hab ich noch eine kleine Spezialfrage: In der alten (recht simpel gestrickten) Version der Software werden für jeden Benutzer individuelle Einstellungen in einer Datenbank abgelegt. Gesetzt den Fall man hat da eine Windows-User-Verifikation, dann könnte natürlich schauen ob ein Benutzer mit dem Namen in der Datenbank schon existiert und wenn nicht den Benutzer dort anlegen.

Ist das ein gangbarer Weg oder ist das aus irgendeinem Grund BÖSE? Und kann es sein, dass ein User seinen Login-Namen ändert so dass der User plötzlich für meine App wie ein neuer User aussieht?

Und zu guter Letzt: Ich schätze Benutzer werden in Gruppen organisiert. Man müsst also bei der Authentifizierung abfragen können ob der Benutzer xxx mit Passwort yyy Mitglied der Gruppe zzz ist. Nur: Wie das alles?

Vielen vielen Dank!
Ralf

[WM_CLOSE]

Du kannst es mit LogonUser versuchen und evtl mit dem programm ifmember die gruppenzugehörigkeit feststellen
Bei LogonUser das Token einfach wieder schließen
Quelle:http://support.microsoft.com/kb/180548 (auf englisch lesen, da die deutsche übersetzung mies ist)

[p80286]

Zitat:

Zitat von ralfiii (Beitrag 1077600)

Nun möchten manche Kunden (meist Krankenhäuser) die Benutzer nicht bei uns und in ihrem Netzwerk einpflegen.

Einer für alle, alle für einen.
Und Datenklau und Datenmanipulation gibt es ja nur bei der US-Regierung!

Zitat:

Zitat von ralfiii (Beitrag 1077600)

Und kann es sein, dass ein User seinen Login-Namen ändert so dass der User plötzlich für meine App wie ein neuer User aussieht?

Davon kannst du aber verschärft ausgehen, ich habe z.B. 4 Identitäten, je nachdem was ich so treiben will.

Zitat:

Zitat von ralfiii (Beitrag 1077600)

Und zu guter Letzt: Ich schätze Benutzer werden in Gruppen organisiert. Man müsst also bei der Authentifizierung abfragen können ob der Benutzer xxx mit Passwort yyy Mitglied der Gruppe zzz ist. Nur: Wie das alles?

Das wäre sinnvoll, aber es kommt darauf an ob diese Gruppen Resourcen oder Funktions-orientiert definiert werden.
Und aus mir unverständlichen Gründen wehren sich viele Benutzer dagegen, in Gruppen "gestopft" zu werden. Aber wenn ich mich mich richtig erinnere, stellt sich ein Benutzer automatisch auch als Gruppenmitglied vor. Du mußt also nur Fragen ist der Benutzer Gruppenmitglied. Eine aufwendige Suche entfällt.

Aber wenn eh nur ein Benutzer sich einloggt (wie wäre es mit SA?), dann ist es doch eh einerlei?

Gruß
K-H

[SirThornberry]

Ich würde ebenfalls mit LogonUser arbeiten. anstelle den Benutzernamen dann weiter zu verwenden würde ich lieber die UserID verwenden um umbenennen etc. mit abzudecken.

[WM_CLOSE]

so villeicht: http://www.delphi-forum.de/viewtopic...highlight=sspi

[p80286]

Zitat:

Zitat von SirThornberry (Beitrag 1077615)

Ich würde ebenfalls mit LogonUser arbeiten. anstelle den Benutzernamen dann weiter zu verwenden würde ich lieber die UserID verwenden um umbenennen etc. mit abzudecken.

Du meinst die SID?

Gruß
K-H

[ralfiii]

Um das Umfeld mal zu simulieren wollt ich schnell so ein Mini-Netzwerk aufbauen (mit virtuellen Maschinen versteht sich).

Kann man ein "normales" WinXP prof. zu einem Domänenkontroller machen (ich schätze sowas brauch ich als Server, oder?)

Ich hab mal angefangen Windows Server 2008 runterzuladen (http://www.microsoft.com/downloads/d...7-32212b520f50)
wenn das simpler ginge, dann wär ich natürlich auch nicht böse.

Danke,
Ralf

[Assarbad]

Zitat:

Zitat von ralfiii (Beitrag 1077600)

(Ein anderes Verhalten wäre wohl den aktuell benutzte Windows-User zu verwenden. Ich schätze das sollte recht einfach hinzukriegen sein, also konzentriere ich mich mal auf den komplizierteren Fall)

Ist ja ohnehin der Fall. Eben nur ohne explizite Abfrage in dem Fall.

Zitat:

Zitat von ralfiii (Beitrag 1077600)

Ich hab mal kurz gegoogelt, da fliegen einem die Begriffe "Active Directory", "Kerberos", "LDAP" etc. nur so um die Ohren - hab davon leider keinen Schimmer davon.

LDAP ist eine Untermenge der seit Windows 2000 (Server) unterstützten ADS (Active Directory Services).

Stell dir das Active Directory als eine Datenbank mit diversen angeschlossenen externen Elementen (Computer, Code) vor. Du kannst dort auch Daten speichern und bspw. über Zugehörigkeit zu einer OU (Organizational Unit) Regeln festlegen. Und das ist definitiv jeglicher selbstgebastelten Lösung vorzuziehen, wenn ADS/LDAP im Zielnetzwerk benutzt wird. Andere Verzeichnisdienste ala Novell bieten sicher auch Möglichkeiten ... aber die kenne ich nicht gut genug.

Zu Kerberos habe ich keine Ahnung. Habe ich noch nie richtig verstanden.

Zitat:

Zitat von ralfiii (Beitrag 1077600)

Ist das ein gangbarer Weg oder ist das aus irgendeinem Grund BÖSE? Und kann es sein, dass ein User seinen Login-Namen ändert so dass der User plötzlich für meine App wie ein neuer User aussieht?

Nur wenn du nach dem Namen gehst. Du solltest entweder die SID oder die RID (letzte Ziffernfolge in einer SID) nehmen.

Zitat:

Zitat von ralfiii (Beitrag 1077600)

Und zu guter Letzt: Ich schätze Benutzer werden in Gruppen organisiert. Man müsst also bei der Authentifizierung abfragen können ob der Benutzer xxx mit Passwort yyy Mitglied der Gruppe zzz ist. Nur: Wie das alles?

Geht sowohl mit ADS/LDAP als auch mit normalen Windowsmitteln (NT-Plattform).

Zitat:

Zitat von ralfiii (Beitrag 1077636)

Kann man ein "normales" WinXP prof. zu einem Domänenkontroller machen (ich schätze sowas brauch ich als Server, oder?)

Für ADS braucht's eine Serverversion. Für nur LDAP gibt es verschiedene andere Lösungen (inklusive Linux).

Für XP gab es eine Art abgespeckten Verzeichnisdienst von MS, der aber im Prinzip mit ADS nicht wirklich vergleichbar ist, sondern eher mit LDAP.

[ralfiii]

Zitat:

Zitat von Assarbad (Beitrag 1077640)

LDAP ist eine Untermenge der seit Windows 2000 (Server) unterstützten ADS (Active Directory Services).

Ok, verstehe. Ich suche eine Lösung mit der ich mit geringem Aufwand eine möglichst grosse Kundenzahl versorgen kann. Da klingt LDAP also nicht schlecht.

Zitat:

Zitat:

Zitat von ralfiii (Beitrag 1077600)

kann es sein, dass ein User seinen Login-Namen ändert so dass der User plötzlich für meine App wie ein neuer User aussieht?

Nur wenn du nach dem Namen gehst. Du solltest entweder die SID oder die RID (letzte Ziffernfolge in einer SID) nehmen.

Ich krieg da einen irre langen String, z.B. S-1-5-21-3926681305-3518172317-3193622278-1107
Ist da nun die "1107" die eindeutige Benutzerkennung?

Und noch eine Kleinigkeit:
Wenn ich LogonUser auf einem Rechner ausführe wo der Benutzer sich an einer Domäne angemeldet hat dann läuft alles perfekt.
Mach ich das bei mit auf meinem Entwicklungsrechner (lokaler Benutzer) und gebe den korrekten Usernamen/Passwort an, dann liefert LogonUser (mit LOGON32_LOGON_INTERACTIVE, oder?) True ganz egal ob ich die Domäne leer lasse oder eine falsche Angebe.
Gebe ich eine falsche Domäne an, dann liefert LookupAccountNameW "Der RPC-Server ist nicht verfügbar." als Fehler. Nix grosses, ist mir nur aufgefallen.

[Assarbad]

Zitat:

Zitat von ralfiii (Beitrag 1077914)

Ich krieg da einen irre langen String, z.B. S-1-5-21-3926681305-3518172317-3193622278-1107
Ist da nun die "1107" die eindeutige Benutzerkennung?

RID == relative ID

Eindeutig ja, aber nur auf diesem Rechner. Nur der komplette irre lange String ist eineindeutig und sollte dies auch global sein (es handelt sich im Prinzip um eine GUID), wobei der Teil am Anfang den Rechner identifiziert. Bei Domänenkonten wäre dies die Domäne, nicht der lokale Rechner.

[musicman56]

Hallo Ralf,

zu allen bisherigen Überlegungen und Beiträgen möchte ich zu bedenken geben: Die Lösung die du implementierst muss letztendlich auch gepflegt werden. Da kommt schon einiges an Aufwand auf dich zu. Der irgendwie aber auch bezahlt werden muss. Und zudem für den Anwender einigermaßen komfortabel sein sollte.

Ich habe eine ähnliche Situation: Eine Datenbankanwendung (Warenwirtschaft) mit kleiner Benutzerverwaltung, die intern einige Zugriffsrechte steuert und regelt. Diese Berechtigungen haben aber direkt NICHTS mit den Berechtigungen im Betriebssystem zu tun, so wie ich das sehe, und wie es bei mir auch ist. Ein OS-Admin muss nicht zwangsläufig auch in meiner Anwendung ein Admin sein, und umgekehrt: Jemand der in deinem Programm alle Rechte hat, muss nicht zwangsläufig auf betriebssystemebene Admin-Rechte haben.

Also macht eine Verknüpfung bestenfalls auf Namens-Ebene Sinn, und so habe ich das bei mir auch gelöst: In meinem Anmelde-Dialog belege ich den Benutzernamen für meine Software mit dem Windows-Benutzernamen vor, sodass der Anwender lediglich sein Passwort - wenn vorgegeben - eingeben muss.

Zitat:

Soweit ich das verstehe ist oft ein Dummy-User an einem Rechner angemeldet...

... und das hält den Aufwand die Benutzer in deinem Programm anzulegen doch sehr in Grenzen. Was wiederum für eine "einfache" Lösung des Problems spricht.

[ralfiii]

Zitat:

Zitat von musicman56 (Beitrag 1077979)

Also macht eine Verknüpfung bestenfalls auf Namens-Ebene Sinn, und so habe ich das bei mir auch gelöst: In meinem Anmelde-Dialog belege ich den Benutzernamen für meine Software mit dem Windows-Benutzernamen vor, sodass der Anwender lediglich sein Passwort - wenn vorgegeben - eingeben muss.

Ich glaube ich habe nun einen guten Weg gefunden:
3 Modi:
1.) Old style (wir verwalten User in der DB)
2.) Single Sign on -> ich verwende den aktuell benutzten Windows user namen
3.) LDAP -> ich überprüfe ob username/passwort auf dem Win-System (gegebenenfalls Domäne) definiert ist.

Für die Fälle 2 und 3 werden - sofern gleichnamige User in der Applikations-DB noch nicht existieren - Benutzer in unser DB angelegt, mit sehr eingeschränkten Rechten. Der Applikations-Admin kann diese Benutzer dann leicht in eine privilegiertere Usergruppe verschieben.

Von der Verwendung der SID sehe ich ab, weil sicher manche (wie auch wir hier in der Firma) ein sehr simples Netzwerk ohne AD haben, d.h. die Benutzer wurden manuell auf allen Rechnern angelegt. Da wäre dann wieder die SID unterschiedlich.

Ralf

[Luckie]

http://de.wikipedia.org/wiki/Security_Identifier Da steht alles.

Eventuell hilft ja diese Unit: http://www.michael-puff.de/Programmi...tePassword.pas
Damit kannst du überprüfen, ob der Benutzer im System existiert und ob er ein korrektes Passwort eingegeben hat.

[ralfiii]

Zitat:

Zitat von Luckie (Beitrag 1078041)

http://de.wikipedia.org/wiki/Security_Identifier Da steht alles.

Eventuell hilft ja diese Unit: http://www.michael-puff.de/Programmi...tePassword.pas
Damit kannst du überprüfen, ob der Benutzer im System existiert und ob er ein korrektes Passwort eingegeben hat.

Das ist eine recht lange Unit und ich kann eigentlich keinen Vorteil gegenüber der sehr simplen Lösung

Delphi-Quellcode:

// Check if a username/password exists on a system
//   if parameter domain is left blank test is performed on the current domain
function CheckUserAccount(Username, Password, Domain : string) : boolean;
var token: THandle;
begin
     LogonUser(PChar(Username), PChar(Domain), PChar(Password),
                    LOGON32_LOGON_INTERACTIVE,LOGON32_PROVIDER_DEFAULT,token);
     CloseHandle(token);
     result:=token<>0;
end;

finden. Danke dennoch!

[himitsu]

Ich dachte LogonUser hat auch noch ein Result, welches man prüfen könnte.
Im MSDN steht nicht drin, daß Token auch im Fehlerfall immer auf 0 gesetzt wird.

Delphi-Quellcode:

function CheckUserAccount(Username, Password, Domain : string) : boolean;
var token: THandle;
begin
  if LogonUser(PChar(Username), PChar(Domain), PChar(Password),
    LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, Token) then
  begin
    CloseHandle(Token);
    Result := Token <> 0;
  end else
    Result := False;
end;

Delphi-Quellcode:

function CheckUserAccount(Username, Password, Domain : string) : boolean;
var token: THandle;
begin
  Result := LogonUser(PChar(Username), PChar(Domain), PChar(Password),
    LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, Token) and (Token <> 0);
  if Result then
    CloseHandle(Token);
end;

[Assarbad]

Vielleicht sollte ich auch noch schnell auf SecureZeroMemory verweisen, wenn das Paßwort schon im Speicher der Anwendung gehalten wird ...

[ralfiii]

Hallo!
Ich grab mal den alten Thread wieder aus.

Zitat:

Zitat von Luckie (Beitrag 1078041)

Eventuell hilft ja diese Unit: http://www.michael-puff.de/Programmi...tePassword.pas
Damit kannst du überprüfen, ob der Benutzer im System existiert und ob er ein korrektes Passwort eingegeben hat.

Die Unit funktioniert bei mir nicht.

Will ich mein Passwort auf meinem lokalen Rechner (der kein Teil einer Domain ist) überprüfen (mit Domain="" oder "localhost" oder "." probiert) krieg ich ein
"Im Projekt LDAP_ActiveDirectory_Test.exe ist eine Exception der Klasse Exception mit der Meldung 'Couldn't query package info for NTLM, error -2146893051\n' aufgetreten."
Die Exception wird zwar gehandled, aber die Funktion liefert immer false zurück.

Teste ich das in an einem Rechner der Teil einer Domain ist, und übergebe den Domainnamen an SSPLogonUser ("graz.local" oder "graz" oder "ldaptest.graz.local" oder "192.168.0.4" probiert), kommt auch immer false zurück. (Evtl auch die Exception, aber dort ist kein Delphi drauf)

Muss ich die Domain oder den Usernamen speziell formatieren?

Oder, ganz anders gefragt: Kann ich User-Credentials (also Name/Passwort) bei einem AD-Domänenserver testen, und das von einem Rechner aus, der NICHT Teil der Domäne ist?

[Luckie]

Puh. Ewig her. Ich hatte damit keine Probleme an einem lokalen Rechner ohne Domain. Eventuell ein Unicode Problem? Die Unit ist noch aus einer Zeit, da hat man bei Delphi noch nicht an Unicode gedacht.

[jobo]

Zitat:

Zitat von ralfiii (Beitrag 1389834)

Muss ich die Domain oder den Usernamen speziell formatieren?

Falls es kein Encodingproblem ist, ein Hinweis zur Login Schreibweise:


Ein Rechnername in einer Windowsdomäne wird klassischer Weise so angegeben:
<DomaineName>\<LoginName>
Ist der Rechner nicht Teil einer Domäne oder möchte man sich explizit mit einem lokalen Account anmelden, dann wäre es so:
<RechnerName>\<LoginName>

Ausprobieren kann man diese Schreibweise ganz gut mit einem Domänenrechner.
Je nach Windowsversion und Einstellungen wird die Domäne (oder der lokale Name) bereits vor der Anmeldung in der Nähe des Logins irgendwo angezeigt. Evtl auch als separates Feld mit Dopdown. Die Anzeige gibt dabei idR den Stand der letzten Anmeldung wieder.

Also:
Man schaue sich die Anzeige an, stelle fest, was vorgegeben wird (letzter erfolgreicher Login) und wähle danach die "gegenteilige" Loginvariante. Dazu im Feld login die oben angegebene Kombination eintragen.
Bereits nach dem Verlassen dieses Feldes wird die Domänenanzeige entsprechend der Eingabe umgestellt und dieser Wert aus dem eingetippten Logintext entfernt.

Mglw. gibt es Konfigurationen von Windows, wo diese Beschreibung nicht funktioniert, ich habe allerdings persönlich noch keine erlebt. Voraussetzunh für das Verfahren ist ein Domänenrechner, ein gültiger Domänenaccount mit Loginrecht auf dem Rechner und ein ebensolcher lokaler Account.
(Der erfolgreiche Test würde m.E. nahelegen, dass auch keine sonstigen Hemmnise vorliegen, die per Profile für den Rechner, den Domänenaccount oder lokale Accounts bestehen. Bei einem lokalen Rechner, der nie in einer Domäne war(!), dürfte es solche Probleme allerdings nicht geben. Exdomänenrechner, die nur entfernt, aber nicht neu aufgesetzt wurden, können unter der Problemen leiden, die durch Reste von Profileregeln verursacht werden)

Hat man den Test erfolgreich an einem Domänenrechner praktiziert, könnte man diesen Wert in der Schreibweise evtl. auch sinnvoll in der Unit verwenden.

[ralfiii]

Ich belebe mal den uralten Thread.
Bin drüber gestolpert, dass LogonUser mit LOGON32_LOGON_NETWORK richtig arbeitet wenn der Benutzername richtig geschrieben wurde.
Wenn's den Nutzer aber nicht gibt, dann liefert LogonUser IMMER true.
Nutzt man LOGON32_LOGON_INTERACTIVE dann funktionieren alle Fälle richtig.

Ich hab die MS-Docu durchgelesen, kapier' aber nicht warum das so ein muss.

Ich stell's mal einfach um in der Hoffnung dass mir nicht andere Siedeffects das Genick brechen.

Jemand eine Idee?