Active Directory user

[a mueller]

hallo an alle,
habe mal eine frage...

Bin dabei ein zeiterfassung zu programmieren.
Ist im vom prinzip wie eine stechuhr.

nutze C# unter visual studio 2003.

Nun zur Frage:
Im ersten window soll sich der benutzer anmelden können, und das ist soweit ja kein problem.
Der Benutzer soll nicht über eine textbox seinen namen eingeben, und die dahinter sich befindende DB soll auch was die Benutzer betrifft nicht gepflegt werden.
Der Wunsch ist eine ComboBox automatisch über die user gruppe des Active directory zu füllen.
Wie kann ich da ran kommen? Gibt es eine fertige Klasse bzw. Methode dafür?
hat jemand einen tipp?
Oder gibt es starke gründe die dagegen sprechen?
Ok... noch ne frage...
Was eignet sich am betsen um ein passwort mit c# zu verschlüsseln, in einer mssql DB?

Freue mich über jeden tipp...
Andreas

[Andreas Kosch]

Hallo,

Im ersten window soll sich der benutzer anmelden können,...

warum dieser Umweg? Wenn sich der Benutzer über den Login-Dialog von Windows legitimiert hat, steht doch bereits die Idenität des Anwenders eindeutig ist.

Im .NET Framework ist der System.Security.Principal-Namespace für die Role-Based Security zuständig. Um eine rollenbasierende Auswertung zu unterstützen, muss die Anwendung auf Objektinstanzen zurückgreifen, die die Interfaces IIdentity (Authentifizierter Benutzer) und IPrincipal (Kombination der Benutzer-Identität mit den Rollen) unterstützen. Das IIdentíty-Interface stellt die Methode Name, IsAuthenticated und AuthenticationType zur Verfügung.

Im .NET-Framework stellt gleich 4 verschiedene Klassen für die Implementierung des IIdentity-Intefaces zuständig, wobei WindowsIdentity die Standard-Authentifizierung von Windows über das Active Directory (Domänenkontroller) abdeckt.

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
System.Security.Principal.WindowsIdentity aWI;
aWI = System.Security.Principal.WindowsIdentity.GetCurrent(); 
this.Text = aWI.Name;

Was eignet sich am betsen um ein passwort mit c# zu verschlüsseln, in einer mssql DB?

Idealerweise wird ein Passwort niemals in einer eigenen Datenbank gespeichert, sondern stattdessen diese Infrastrukturaufgabe auf das Betriebssystem abgewälzt. Wenn schon der Benutzername mit seinem Passwort in der eigenen Datenbank gespeichert werden soll, darf dann nur der Hashwert des Passworts in der Datenbank landen. Der Hashwert als digitaler Fingerabdruck ist eine "Ein-Weg-Verschlüsselung" und kann niemals wieder in den Klartext zurückgewandelt werden. Um den Benutzer zu legitimeren, berechnet der C#-Client nach der Passworteingabe im Formular den Hashwert neu und vergleicht diesen mit dem in der Datenbank gespeicherten Wert. Wenn dann noch ein Salt-Wert eingemischt wird, greifen sogar Wörterbuch-Angriffe ins Leere.
Im .NET Framework sind die Klassen aus dem Namespace System.Security.Cryptography auch für die Ermittlung des Hashwertes zuständig. Die Methode ComputeHash wird dort von verschiedenen Klassen wie zum Beispiel SHA1CryptoServiceProvider oder MD5CryptoServiceProvider angeboten

[a mueller]

mhh...

ich danke Dir erstmal für die kompetente Aussage...
Die Sachlage, die du schilderst mit dem Active Directory Controler leuchtet sehr ein.
Wenn ich das richtig verstanden habe gibt es das client server prinzip.
Erste idee von mir war es nur die datenbank zu haben und die clientrechner regeln es darüber.
Client.exe server.exe, und somit kann ich das passwort bzw. die Anmeldung besser und sicherer händeln.
Bin gerade dabei mir die basis und idee zu schaffen, oder zu optimieren.
Wir groß ist denn der Aufwand mit einer client server basis.
Wrde das hauptprogramm dann auf den server legen und die Benutzer können sich dann dort anmelden und sich für ihre tätigkeiten eintragen.

Gibt es hier beispiel projekte?
Hab noch nie in tcp oder netwerkprogrammierung programmiert.

Bin ein java kind.

[Andreas Kosch]

Hallo,

...und somit kann ich das passwort bzw. die Anmeldung besser und sicherer händeln.

auch dann, wenn die Anwendung eine Tree-Tier-Architektur nutzt (d.h. die Benutzeroberfläche ruft nur ein auf dem Anwendungsserver installiertes Geschäftsobjekt auch, welches dann auf die Datenbank zugreift), bleibt das primäre Problem erhalten. Denn wenn der Anwender in der Benutzeroberfläche das Passwort eintippt, muss dieses ja zum Server transportiert werden. Da ein Network-Sniffer nicht ausgeschlossen werden kann, bleibt das Sicherheitsproblem bestehen.

Was spricht dagegen, nur den von WindowsIdentity zurückgelieferten Namen des Anwenders (in der Syntax Domänenname\Benutzername) zu verwenden. Die eigenen Datenbank kann so jeden Benutzer eindeutig identifizieren, ohne dass eine Sicherheitslücke entsteht.

Hab noch nie in tcp ...programmiert.

Das ist auch gar nicht mehr notwendig. Denn anstelle der Low-Level-Funktionen ist einer der im .NET Framework einsatzfertigen Wege besser geeignet:

a) .NET Enterprise Service
b) .NET Remoting
c) XML Web Services
d) WCF

Je nach den Anforderungen ist einer der Wege am Besten geeignet.

[a mueller]

Danke

ist jetzt verstanden.
werde gleich mal testen und lesen...
kannst du mir den WindowsIdentity mit deinen worten genauer beschreiben...
und die funktion...
sowie den ablauf des programmes unter windows....


wäre nett....

danke

Andy