Develop Reference

C# Simple login interface with SQL data model

So i'm doing a course on C#, where i´ve been tasked to build an app for a fictive company.
In the app needs to be a login screen, i´ve been struggling with getting it to accept my correct login parameters (See code). Instead it says every entry is incorrect.
Can any of you spot the immediate issue with my code?
private void button1_Click(object sender, EventArgs e)
{
logindbEntities context = new logindbEntities();
if (textBox1.Text!=string.Empty || textBox2.Text!=string.Empty)
{
var user = context.AdminLogin.Where(a =>
a.Full_name.Equals(textBox1.Text)).First();
if (user != null)
{
if (user.Password.Equals(textBox2.Text))
{
success s1 = new success();
s1.Show();
}
else
{
MessageBox.Show("password is not correct");
}
}
else
{
MessageBox.Show("username is not registered");
}
}
else
{
MessageBox.Show("username & password are required");
}
EDIT: Have me excused please, i´ve tried to edit the post to suit the guidelines better.

Firstly, you may get the username and password into two variables from your form.
string username="";
string password="";
After you get the username and password from your form into the two variables, it's time to check it with the database.
var user = context.AdminLogin.Where(a => a.Full_Name.Equals(username)).First();
Then, check if the sequence does not contain any element, the user does not exist. You may use message box to display that it does not exists.
if(!user.Any()) // Show message here --user does not exist--
Then, if the user exist. You may check the password.
if(user.Password.Equals(password)) // Handle password here.

How to do client-side validation of password change in Active Directory

My objective is simple: pre-validate a new password client-side (Javascript) as an initial check the password matches the domain/ou password policy, to avoid wasting server resources rejecting bad passwords and give faster responses to users.
The question: How can I get user password policy from Active Directory?
I especially need to know the password "format", password length, capital and special characters requirements, etc. The final validation will, of course, be Active Directory itself. But first I want to use Javascript as a performance optimization, and I'm pretty sure I can manage the Javascript if I can just retrieve the password format requirements for a specific user/OU on the C#/ASP.Net end.
Currently, I'm stuck trying to find WHAT the current password policy is for the user. Yes, user Alice might use the password domain policy, but Bob could have a different password policy in his OU.
This website will be installed in an institution with thousands of users; we want to minimize the back and forth validation against Active Directory. Additionally, having this in Javascript can eventually help in compliance with NIST Special Publication 800-63, which among other things asks for prompt feedback to users on relative password strength. For now, I must be able to make the code work on Windows 2008, 2008 R2 and 2012.
I'm currently able to change the password in C#, and I can get the error, but it's it's all or nothing, and not helpful for client-side validation.
public static PasswordChangeResultsDTO ChangeUserPassword(PasswordChangeRequestDTO request)
{
try
{
bool isPasswordChanged = false;
SearchResult result = LdapHelper.GetUser(request.Username, request.OldPassword);
if (result != null)
{
using (DirectoryEntry userEntry = result.GetDirectoryEntry())
{
userEntry.Invoke("ChangePassword", new object[] {request.OldPassword, request.NewPassword});
userEntry.CommitChanges();
isPasswordChanged = true;
}
}
return new PasswordChangeResultsDTO {PasswordChanged = isPasswordChanged};
}
catch (COMException comException)
{
LoggingHelper.Instance.WriteException(comException);
string message = comException.ErrorCode == -2147022651
? "The password does not meet the password policy requirements"
: comException.Message;
return new PasswordChangeResultsDTO {PasswordChanged = false, Message = message};
}
catch (TargetInvocationException targetInvocationException)
{
LoggingHelper.Instance.WriteException(targetInvocationException);
string message;
if (targetInvocationException.InnerException != null)
{
var comException = targetInvocationException.InnerException as COMException;
if (comException != null)
{
message = comException.ErrorCode == -2147022651
? "The password does not meet the password policy requirements"
: comException.Message;
}
else
{
message = targetInvocationException.InnerException.Message;
}
}
else
{
message = targetInvocationException.Message;
}
return new PasswordChangeResultsDTO {PasswordChanged = false, Message = message};
}
catch (Exception ex)
{
string msgError = (null != ex.InnerException) ? ex.InnerException.Message : ex.Message;
string msgSource = (null != ex.InnerException) ? ex.InnerException.Source : ex.Source;
string msgStackTrace = (null != ex.InnerException) ? ex.InnerException.StackTrace : ex.StackTrace;
string msgOutput = String.Format(CultureInfo.InvariantCulture,
"Exception in {3} MSG[{0}] SOURCE[{1}] STACK[{2}]",
msgError, msgSource, msgStackTrace, MethodBase.GetCurrentMethod().Name);
LoggingHelper.Instance.Fatal(msgOutput);
throw;
}
}

Finding out this information at the domain level is easy. Figuring out if any Group Policies have overridden the default is hard.
At the domain level, there are attributes at the domain itself that govern the default password policy for the domain. You can bind to the domain itself (i.e. LDAP://domain.com) and read these attributes:
minPwdLength: The minimum character length
pwdHistoryLength: The number of old passwords that can't be reused.
pwdProperties: This is a bit flag that could mean various things, which you can read about under the "PasswordProperties" section here. It's likely to be set to 1 (DOMAIN_PASSWORD_COMPLEX), which means a password must include at least two of either uppercase, lowercase and numbers.
If you want to go through the effort to read group policies that would apply to the user's OU, there doesn't seem to be any .NET libraries to do that. You have to resort to using unmanaged code. There is an example here that uses the IGPMDomain interface from C#, but you will have to adapt it to find the GPO for the right OU.

C# Nested impersonation - impersonate a user whilst already impersonating another

I have a fairly odd requirement to be able to impersonate a user, when I'm already impersonating another, using C#.
I'm writing an app to allow the management of Active Directory users. This app will provide the ability for anyone in the company to view and maintain certain details about themselves (some of which will not actually be saved to Active Directory, but some of which will), for managers to be able to view and maintain details about their team, and for HR to be able to view and maintain details about anyone.
For obvious reasons I don't want to develop or test this against the live domain. We have recently ported all users over to this domain from another domain, which means I can actually test against the old domain without affecting anything. However, to enable me to do this I have to impersonate my old account on the old domain, which I do on loading the application.
Although for me everything will work fine as I'm setup as a domain admin, going forward obviously not all users will be domain admins, and won't be able to write to AD under their own account, and therefore we have another domain admin user setup specifically for this application, whenever data needs to be saved to AD that user is impersonated. This was working great before when I was testing against an Active Directory I'd setup on a virtual machine because I was logging onto the local domain, however that didn't allow me to step through the code in Visual Studio so debugging was slow, and hence I've stopped using that virtual machine and am using this old domain. Now I'm already impersonating another user (i.e. my old domain account), when it then tries to impersonate the domain admin user it fails with an "System.Security.SecurityException: Access is denied." exception. The line this fails on is just writing out some debugging information using "WindowsIdentity.GetCurrent().Name".
If I change my code so I'm actually logging in using the new domain admin rather than my old account, the first time it goes through it logs in successfully (so the credentials are correct), however when it then goes through and tries to do the same again to write to AD it fails with the above exception. Therefore I think it must be a problem with trying to do a nested impersonate.
Is it possible to do a nested impersonate?
Below is the code I'm using:
private static WindowsImpersonationContext ImpersonateUser(out string result, string sUsername,
string sDomain, string sPassword)
{
// initialize tokens
var pExistingTokenHandle = new IntPtr(0);
var pDuplicateTokenHandle = new IntPtr(0);
// if domain name was blank, assume local machine
if (sDomain == "")
{
sDomain = Environment.MachineName;
}
try
{
result = null;
const int logon32ProviderDefault = 0;
// create token
const int logon32LogonInteractive = 2;
// get handle to token
var bImpersonated = LogonUser(sUsername, sDomain, sPassword,
logon32LogonInteractive,
logon32ProviderDefault,
ref pExistingTokenHandle);
// did impersonation fail?
if (!bImpersonated)
{
var nErrorCode = Marshal.GetLastWin32Error();
result = "LogonUser() failed with error code: " + nErrorCode + "\r\n";
}
// Get identity before impersonation
result += string.Format("Before impersonation: {0}\r\n", WindowsIdentity.GetCurrent().Name);
var bRetVal = DuplicateToken(pExistingTokenHandle, (int)SecurityImpersonationLevel.SecurityImpersonation,
ref pDuplicateTokenHandle);
// did DuplicateToken fail?
if (bRetVal)
{
// create new identity using new primary token
var newId = new WindowsIdentity(pDuplicateTokenHandle);
var impersonatedUser = newId.Impersonate();
// check the identity after impersonation
result += "After impersonation: " + WindowsIdentity.GetCurrent().Name + "\r\n";
return impersonatedUser;
}
else
{
var nErrorCode = Marshal.GetLastWin32Error();
CloseHandle(pExistingTokenHandle); // close existing handle
result += "DuplicateToken() failed with error code: " + nErrorCode + "\r\n";
return null;
}
}
finally
{
// close handle(s)
if (pExistingTokenHandle != IntPtr.Zero)
{
CloseHandle(pExistingTokenHandle);
}
if (pDuplicateTokenHandle != IntPtr.Zero)
{
CloseHandle(pDuplicateTokenHandle);
}
}
}
When this is called for the nested impersonation which fails, "bImpersonated" is actually "true", as is bRetVal, which suggests its worked, however when it gets to "WindowsIdentity.GetCurrent().Name" it fails with the exception above.
I hope this makes sense, and would appreciate any assistance.

WCF impersonation is not impersonating an administrator

I am trying to use WCF to do some remote user management things. I and reusing some code I had on a server 2003 box and worked fine, but on my windows 7 test box when I check to see if the user who called the function is administrator it says it is not.
[OperationBehavior(Impersonation=ImpersonationOption.Required)]
public string SetPassword(string username)
{
WindowsPrincipal principal = new WindowsPrincipal(OperationContext.Current.ServiceSecurityContext.WindowsIdentity);
System.Diagnostics.Debug.Print(WindowsIdentity.GetCurrent().Name);
System.Diagnostics.Debug.Print(principal.Identity.Name);
if (principal.IsInRole(WindowsBuiltInRole.Administrator))
{
//try
{
lock (Watchdog.m_principalContext)
{
using (UserPrincipal up = UserPrincipal.FindByIdentity(Watchdog.m_principalContext, username))
{
string newpassword = CreateRandomPassword();
up.SetPassword(newpassword);
up.Save();
return newpassword;
}
}
}
//catch
{
return null;
}
}
else
throw new System.Security.SecurityException("User not administrator");
}
principal.IsInRole(WindowsBuiltInRole.Administrator) is returning false every time. Both my current identity and principal.idenity are the correct user to be impersonated. and that user is a member of the administrators user group.
I think it has to do with UAC that was implemented in windows vista and up. this will be a issue because the production machine this will be going on to is a win2k8-r2 box.
Any suggestions on what to do?

Take a look at this article, under the section, "Coping with Windows Vista" , a very well written article with about UAC and checking Admin privs programatically.

As I did not want to do all that work (from RandomNoob's post) for check if the user is an administrator and the service is already running in a administrative context, I decided to just drop impersonation. I created a new user group called WCFUsers and anyone who will be using the service was added to that group. It now does the System.DirectoryServices.AccountManagement operations in its own context.
[OperationBehavior(Impersonation=ImpersonationOption.NotAllowed)]
public string SetPassword(string username)
{
WindowsPrincipal principal = new WindowsPrincipal(OperationContext.Current.ServiceSecurityContext.WindowsIdentity);
if (principal.IsInRole("WCFUsers"))
{
try
{
lock (Watchdog.m_principalContext)
{
using (UserPrincipal up = UserPrincipal.FindByIdentity(Watchdog.m_principalContext, username))
{
string newpassword = CreateRandomPassword();
up.SetPassword(newpassword);
up.Save();
return newpassword;
}
}
}
catch
{
return null;
}
}
else
return null;
}

Create Active Directory user in .NET (C#)

I need to create a new user in Active Directory. I have found several examples like the following:
using System;
using System.DirectoryServices;
namespace test {
class Program {
static void Main(string[] args) {
try {
string path = "LDAP://OU=x,DC=y,DC=com";
string username = "johndoe";
using (DirectoryEntry ou = new DirectoryEntry(path)) {
DirectoryEntry user = ou.Children.Add("CN=" + username, "user");
user.Properties["sAMAccountName"].Add(username);
ou.CommitChanges();
}
}
catch (Exception exc) {
Console.WriteLine(exc.Message);
}
}
}
}
When I run this code I get no errors, but no new user is created.
The account I'm running the test with has sufficient privileges to create a user in the target Organizational Unit.
Am I missing something (possibly some required attribute of the user object)?
Any ideas why the code does not give exceptions?
EDIT
The following worked for me:
int NORMAL_ACCOUNT = 0x200;
int PWD_NOTREQD = 0x20;
DirectoryEntry user = ou.Children.Add("CN=" + username, "user");
user.Properties["sAMAccountName"].Value = username;
user.Properties["userAccountControl"].Value = NORMAL_ACCOUNT | PWD_NOTREQD;
user.CommitChanges();
So there were actually a couple of problems:
CommitChanges must be called on user (thanks Rob)
The password policy was preventing the user to be created (thanks Marc)

I think you are calling CommitChanges on the wrong DirectoryEntry. In the MSDN documentation (http://msdn.microsoft.com/en-us/library/system.directoryservices.directoryentries.add.aspx) it states the following (emphasis added by me)
You must call the CommitChanges method on the new entry to make the creation permanent. When you call this method, you can then set mandatory property values on the new entry. The providers each have different requirements for properties that need to be set before a call to the CommitChanges method is made. If those requirements are not met, the provider might throw an exception. Check with your provider to determine which properties must be set before committing changes.
So if you change your code to user.CommitChanges() it should work, if you need to set more properties than just the account name then you should get an exception.
Since you're currently calling CommitChanges() on the OU which hasn't been altered there will be no exceptions.

Assuming your OU path OU=x,DC=y,DC=com really exists - it should work :-)
Things to check:
you're adding a value to the "samAccountName" - why don't you just set its value:
user.Properties["sAMAccountName"].Value = username;
Otherwise you might end up with several samAccountNames - and that won't work.....
you're not setting the userAccountControl property to anything - try using:
user.Properties["userAccountControl"].Value = 512; // normal account
do you have multiple domain controllers in your org? If you, and you're using this "server-less" binding (not specifying any server in the LDAP path), you could be surprised where the user gets created :-) and it'll take several minutes up to half an hour to synchronize across the whole network
do you have a strict password policy in place? Maybe that's the problem. I recall we used to have to create the user with the "doesn't require password" option first, do a first .CommitChanges(), then create a powerful enough password, set it on the user, and remove that user option.
Marc

Check the below code
DirectoryEntry ouEntry = new DirectoryEntry("LDAP://OU=TestOU,DC=TestDomain,DC=local");
for (int i = 3; i < 6; i++)
{
try
{
DirectoryEntry childEntry = ouEntry.Children.Add("CN=TestUser" + i, "user");
childEntry.CommitChanges();
ouEntry.CommitChanges();
childEntry.Invoke("SetPassword", new object[] { "password" });
childEntry.CommitChanges();
}
catch (Exception ex)
{
}
}