Windows Benutzerverwaltung mitverwenden

[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 von musicman56:

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 von 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.

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 von Luckie:

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 von ralfiii:

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?