I have a web site using https and basic authentication. User is automatically authenticated against Windows. The web site is hosted on a workgroup computer (not member of a domain). I'm working with .NET Framework 4 and C#
I try to change the password of the user from a web page (after the user is authenticated) without success. I tried several things using DirectoryService like :
using (DirectoryEntry directoryEntry = new DirectoryEntry(string.Format(#"WinNT://localhost/{0}, user", userName), domainAndUser, userPassword))
{
directoryEntry.Invoke("ChangePassword", new object[] { oldPassword, newPassword });
directoryEntry.CommitChanges();
}
I receive an access denied error. I guess I need to be admin to do this.
Is what I try to do possible and how to achieve that ?
Thanks in advance for your answers !
Christian
You have to run that code impersonated as administrator on your workgroup computer, have a look at ASP.NET Impersonation and ASP.NET Runtime Impersonation
Related
We have got a ASP.Net 4.7 MVC project in Azure which handles the user reset password with Identity. The user click on Forgot Password and they get an email with link to the website with a token. This works on MVC, but not on the API. The code that generates the token is shared on both application, so we think it is probably down to have a different machine key.
The code for resetting the password is this which I think it is ok:
var userManager = Users.User.GetApplicationUserManager();
var result = userManager.ResetPassword(userId, token, password);
return result.Succeeded;
I had a look at the rootweb.config for the MVC and the API and they have different machine keys provided by Azure. This may be the problem. Is there a way to share the same machine key in Azure so reset password works?
Thanks
I added the machine key in the web.config files for both applications to have the same.
I'm trying to set up an ASP.NET application to use Windows Authentication.
But the IIS server is not part of a domain, it is a sole server hosted in our Rackspace account.
I'd like to have the Windows Authentication module validate against the list of local Windows users on the IIS server. Is this possible?
Anonymous Authentication is off
Basic Authentication is off
Windows Authentication is on
But when I enter credentials for a local machine account as
machinename\user
password
it doesn't seem to work. It just prompts me again.
Is possible make a local machine validation, like this:
var bool valid = false;
using (var context = new PrincipalContext(ContextType.Machine))
{
valid = context.ValidateCredentials(username, password);
}
It appears that you can use local accounts, but I'm getting some kind of server error when the account tries to authenticate.
Once I found the error in the event logs, and got the status code, I was able to track it down, and find this answer, which worked exactly!
I have an ASP.NET application that uses Forms Authentication.
I need to call the Sharepoint search.asmx web service to retrieve a list of files from the network satisfying the search criteria (there's a good reason for me doing this outside of Sharepoint)
I'm not sure of the security information I need to pass the search.asmx. I've tried:
queryService.ClientCredentials.Windows.ClientCredential = System.Net.CredentialCache.DefaultNetworkCredentials
queryService.ClientCredentials.Windows.AllowedImpersonationLevel = Security.Principal.TokenImpersonationLevel.Impersonation
-which works in my development environment as my user has access to the File Shares Sharepoint is accessing. What I can't understand, and can't infer from debugging or event viewers, etc. is what credentials are passed in the above code once I deploy this code on a server.
Will it pass the windows credentials of the user who opened the IE window prior to using forms authentication. Will it pass the credentials of the account that is running the asp.net components i.e. the account of the AppPool I'm running in, or will it pass something else?
I can't seem to get Sharepoint to return any files and I guess it's because the credentials being passed don't have access to the File Share.
Thanks
Andy
To get this working quickly you can access the SharePoint webservices with your username & password. This isn't the best solution long term obviously.
Set the Credentials property on the SharePoint webservice proxy to your username & password:
spProxy.Credentials = new NetworkCredential("username", "password", "domain");
You'll need to make sure the credentials property is set before you call the webservice.
I'm not a SharePoint expert (I've only used it as a developer), but I believe it only uses Windows authentication to secure the webservices. So forms authentication isn't going to help you out here if you want to access the webservices as the logged in user (unless you're validating the username & password manually with LDAP). ASP.NET Impersonation & Delegation only makes sense if you are using Windows authentication.
As stated by pseudocoder you might want to setup a special account to access SharePoint from the web server.
In my previous questions I was asking how to use windows authentication within my application. That is now working, users can login with there account but I have one database access scenario I can't find anything on.
Basically I will have several servers and here is the problem.
On some servers they will have Windows Authentication accounts for the SQL Server database server, so using impersonate their credentials should be used. But I notice its a global setting in the web.config (not per connection) and it one case I want to use the applications (IIS or ASP) Windows Authentication account rather than the users. (Access to my configuration database)
How could I achieve this?
Web Application is ASP.NET MVC hosted on Server 2003/2008 IIS 6/7/7.5 with clients being Windows XP and above. Using SQL Server Express/Standard 2005/2008 mixed.
Impersonation is on a site wide basis, or you can manually turn it on. What you can't do is manually turn it off I'm afraid, nor can it be done via the connection strings.
So basically turn impersonation off, then wrap the database calls when impersonation is needed like so:
using System.Security.Principal;
WindowsIdentity winId = (WindowsIdentity)HttpContext.Current.User.Identity;
WindowsImpersonationContext ctx = null;
try
{
ctx = winId.Impersonate();
// Do your thing
}
catch
{
}
finally
{
if (ctx != null)
ctx.Undo();
}
The MSDN P&P guide to asp.net impersonation has more.
You'll have to set up delegation on your network so that the ASP.NET servers can impersonate users on the Sql server machines. This assumes your servers are on an Active Directory controlled network (not workgroups) and that the sql servers are on different machines than your web servers.
You would configure delegation for those database server machines where you want the users to be impersonated and don't configure it for those server machines that you want the ASP.NET worker process account to be the account accessing the server.
If you can't do this, you can turn off windows/mixed authentication on the Sql Server instances you wish to prevent delegation on, and then manually configure the Sql Server account to connect with in the connection string within web.config.
Use domain controller - so it could propagate same credentials for single user across entire domain.
The second trick for workgroups - create same account of impersonation (with exactly same login and password) on both servers (ASP and SQLServer). Don't forget to grant this permission on SQLServer.
I made an application that access CRM's web service. The problem is, when I deployed the dll into Sharepoint server, it returned error 401 unauthorized. Apparently the System.Net.CredentialCache.DefaultCredentials didn't work (my suspicion). Here's the code.
CrmSdk.CrmAuthenticationToken token = new CrmSdk.CrmAuthenticationToken();
token.AuthenticationType = AuthenticationType.AD;
token.OrganizationName = ORGANIZATION_NAME;
CrmService service = new CrmService();
service.Url = "http://crmserver:5555/mscrmservices/2007/crmservice.asmx";
service.CrmAuthenticationTokenValue = token;
service.PreAuthenticate = true;
service.Credentials = System.Net.CredentialCache.DefaultCredentials;
It goes vice-versa.
When I made application that access Sharepoint's webservice (coding the plugin) and deployed it to CRM server. It couldn't access the Sharepoint's web service. Unauthorized error. Here is the code:
Lists listService = new Lists();
listService.PreAuthenticate = true;
listService.Credentials = System.Net.CredentialCache.DefaultCredentials;
listService.Url = "http://sharepointserver/webname/_vti_bin/Lists.asmx";
My CRM server and Sharepoint server are in the same domain.
For both code, if I changed the credentials part into something like this then deploy it on server, it can run.
service.Credentials = new NetworkCredential("username", "password", "domain");
Still, I don't want to do this because it reveals user's password in the code. May anyone help me?
The IIS in both server doesn't allow Anonymous Access and it uses Integrated Windows Authentication.
Thank you
From my local computer, I can access the CRM web services or Sharepoint web services. I guess I'm authorized because the DefaultCredentials sent my credentials that its password is saved in the "Stored Username and Password" (Control Panel > User Accounts > tab Advanced > Manage Passwords)
This way, I don't have to type:
service.Credentials = new NetworkCredential("username", "password", "domain");
and my DefaultCredentials from my local comp is authorized to access the web services.
I tried to implement this on the Sharepoint server that access CRM web services. and..tadaa..it won't work. hahaha..
can we inject credentials to DefaultCredentials in server?
the last thing I want to do is to hardcode the useraccount (like the code above)
Could be that you need to be running Kerberos for authentication, but cannot be sure and it is a pain to setup just to check.
Have you verified that the default credentials are the same as those when you explicitly state them? It could be that the default credentails are those of another account that you wouldn't expect.
EDIT #1: Per the remarks for the DefaultCredentials property on MSDN:
DefaultCredentials represents the
system credentials for the current
security context in which the
application is running. For a
client-side application, these are
usually the Windows credentials (user
name, password, and domain) of the
user running the application. For
ASP.NET applications, the default
credentials are the user credentials
of the logged-in user, or the user
being impersonated.
You'll also want to ensure that the user accessing the CRM page (making the call to the SharePoint web service) can access the web service with their credentials and vice versa. If they can then it would seem more likely that some kind of impersonation is happening.
Edit #2: Assuming that you have access to both the CRM and SharePoint server you might take a peak into both the application and system logs. One or both should likely indicate a failed login and indicate which account attempted to access the resource (in this case the web services).
By using DefaultCredentials means the ASP.NET worker process or IIS worker process will take the credential of the user who run the IIS Application Pool.
so if your Dynamics CRM Application Pool is run under a user account Custom-CRM-Domain\JohnDoe, that means it will take the privileges under user account Custom-CRM-Domain\JohnDoe.
Please check the user account who run the application pool of the CRM\Sharepoint Application IIS Web application.
These are the steps to check the Application Pool:
Open the website -> Right Click -> Choose Properties
Select the Home Directory tab
Notice the Application Pool name at the dropdownlist below
Now, go to the Application Pools folder
Try to find the Application Pool name which has been listed in the step 3 -> Right Click and choose Properties
Select the "Identity" tab and you will find the user account who run the application pool
Hope this helps.
service.Credentials = System.Net.CredentialsCache.DefaultNetworkCredentials;
Try that.
Not familiar with Sharepoint, but can't you just store the connection information in a configuration and use built in tools for securing your web.config? Thats what I do.
https://web.archive.org/web/20211029043331/https://aspnet.4guysfromrolla.com/articles/021506-1.aspx
to be able use defaultcredentials, the user in active directory must be defined both in SharePoint and CRM and have enough privileges to do what you are doing with code.
And try to use sdk (crm have helper classes) instead of service definitions.
For fixing this issue you need to know first which user is running the App pool as the others said and if you need to use CredentialCache.DefaultCredentials then you have to add the user lets say svcadmin or the like into "Secondary site collection administrator" by running SharePoint central administration application . By that SP allows to the user which the credential has been passed through to access the things it needs.