I know this is a bit basic, but I'll be eternally grateful if someone could set me straight on this.
I have a bunch of Windows 2012 R2 servers running Hyper-V.
An XML-RPC web service runs on these servers. There is some hosted Powershell behind this. It works perfectly.
The hosted Powershell code runs via impersonation. Again, works great.
Even though these machines have always been in a domain, XML-RPC authentication has worked like this:
I have used a period (".") for domain.
I have used the username "Administrator".
I have used a distinct password per 'local' administrator account.
I have recently added clustering functionality to my application, this is just in the form of some of wrappers for Microsoft's Powershell cmdlets, plus my own stuff.
If I read the dcos correctly, clustering can only be administered with domain credentials. I want my web service to run under a single set of credentials (to simplify the details the calling application needs to store).
I assumed I would wiggle the authentication model like this:
Have a domain user for each Hyper-V host.
Ensure that this user was a member of the local admin and hyper-v administrator groups.
Add these users to a 'clustered hyper-v hosts' group, give this group "clustering permissions' through the clustering administration tools.
My problems:
When running the tweaked model my code has exploded and no longer works, lots of authentication errors, I can sit and see things hitting the registry and being denied.
If I pick a host at random, log on to it with this new domain user (which - to be clear- is a member of the local admin group) and run my code without the xml-rpc wrapper, I seen lots of authentication error. It is as if this user is not running with administrative credentials, even though it has these permissions.
These users also seem to have restricted clustering permissions, even though they should have full access.
If I run the 'test-cluster' command, it will tell me I do not have permissions on the host I am running it on.
I am willing to admit I have an broken directory, or genuine access problems here, but perhaps I have an inherent misunderstanding of how this is supposed to work.
I am a Linux engineer and programmer, I know a bit of Windows. I am a little confused as how UAC is working in this context, in a domain environment, when I am not logged on as the true administrator account...
If I right click a Powershell window and 'run as' administrator, my code all appears to work, even the clustering stuff (which I am lead to believe, through docs, should not run as a local admin).
Am I hitting some kind of elevation issue here? If a domain user has 'effective permissions' (hopefully that term is not confusing things) to do some stuff, does it still have to be elevated in some way?
Thanks very much.
Change UAC to the lowest level(Never Notify), reboot and try again.
I faced similar issue with runing powershell from imperosnated C# application.
I used PowerShell Community Extensions https://pscx.codeplex.com/ to list active privileges inside PowerShell script.
Add this snipet to your PS script:
Import-Module Pscx
Get-Privilege
Let it run with working and non-working credentials, compare those lists of privileges.
If you find some privileges disabled (but not missing), try to enable them in such way:
Import-Module Pscx
$setPriv = new-object Pscx.Interop.TokenPrivilegeCollection
$setPriv.Enable('SeTcbPrivilege')
$setPriv.Enable('SeDebugPrivilege')
Set-Privilege -Privileges $setPriv
Related
We are having several departments with individual Service-Accounts on a Windows Domain (Active Directory) and want to use them to impersonate a console command to run it with Process.Start and set the username and password in the code. Process.Start requires a ProcessInfo class object, where a domain, username and password can be provided.
The commands need to be run under these Service-Account credentials to access related network-shares and manipule their structure and files with a cli-program.
The problem is, that all tries so far with running Process.Start within a webservice or api on a IIS server, we still got into the same problem: It seems to be required, that ProcessInfo can only use the other credentials, if the particular user is having login permissions on the running machine.
All the service users are not having rights to directly login to the machine, so the command cannot be run and an Exception is throwing.
Exception message:
Logon failure: the user has not been granted the requested logon type at this computer
Workaround:
To properly run these commands, we are thinking about creating multiple instances of the webservice/api and impersonate it via the IIS AppPool and assign the relevant service user. Each instance will then have a specific service run in which context IIS is serving the webservice/api.
Our goal is to accomplish the webservice/api in a single instance and change user credentials dynamically grabbed from database (username/password).
Is this possible in any way?
Like ServiceUsers can be assigned to windows service (machine/server), which are not needing login permissions.
I just want to ask, before we going the way of the workaround and creating several instances for this solution... Any helping comments or different ideas of solving this challenge are welcome. Thank you, folkz.
The missing logon type may well be "Log on as a batch job" - see if granting the service accounts this right helps.
The exact steps to achieve this might vary between different versions of Windows but will be something like this;
Start the "Local Security Policy" app (AKA secpol) Go to Security
Go to Settings | Local Policies | User Rights Assignment
Edit "Log on as a batch job" and add your service account
If this does not work then don't forget to undo the above - don't leave experimental security changes lying around!
I have an MVC web application that is supposed to allow users to download files that are stored as UNC paths in a database. These files can be in any number of locations on remote servers/shares.
E.g. Server 1 hosts the web application that is used to download a file stored on Server 2
I do not want to give permissions to these folders to the hosting service account, as the security should be dependent on what the user has access to. Therefore, I'm attempting to use Impersonation to retrieve the file.
When I debug on my local machine, everything works great. It impersonates my user and downloads the file.
When I deploy to my test server, I'm getting the following error:
Access to the path '\\Server2\SharedFolder\somefile.txt' is denied
I've tried various pieces from this Microsoft link, but am not having much luck.
Scenarios I've tried:
Just giving the permission to the service account of the AppPool works fine, but as I said, isn't ideal
Implementing the Impersonate a Specific User in Code from the above article, which works perfectly with a hard-coded user and password. This situation is also not ideal.
Implementing the Impersonate the Authenticating User in Code from the above article. This seems to be exactly what I need, but this is what generates the Access Denied error.
The Code that I want to work:
System.Security.Principal.WindowsImpersonationContext impersonationContext;
impersonationContext =
((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate();
//Code to read all bytes from the file path
impersonationContext.Undo();
I have logging, and System.Security.Principal.WindowsIdentity.GetCurrent().Name after the impersonation does return the intended user (my account instead of the service account), so it does appear to be working.
I thought maybe it was a double-hop thing, so I have also added SPNs for the server and the service account, making sure their Delegation in AD was set to allow for any service. That hasn't helped either.
This question seems to have the exact same problem as me, but there's no follow-up on what the final solution was. I did try the Process Monitor part, but it didn't help at all.
I'm at a loss to why Impersonation seems to be working, but I'm denied access to a file on a second server.
Update 1
I've played around more with my IIS settings and trying to get Kerberos properly set up. The only thing enabled in my IIS Authentication is "Windows Authentication".
When I spit out details after my Impersonate() call, I'm finding that ImpersonationLevel = Impersonation
Is that how it should be, or should that be returning Delegation ?
It would seem the issue was mostly due to my setup with Kerberos and SPNs. I undid all my settings and re-registered my service account, and the Impersonation ended up working properly.
The issue now is that it only seems to work with Internet Explorer. Chrome and MobileIron are doing something different that prevents the ImpersonationLevel of Delegation. That's a whole other question...
I have two Windows services (one runs as network service and the other runs as local system). And the system in which these services are running are part of domain. These services uses active directory as central store and the idea is to be able to add/remove/read entries from this store.
We are simply using System.DirectoryServices.Protocols.LdapConnection.BeginSendRequest(DirectoryRequest request .... http://msdn.microsoft.com/en-us/library/system.directoryservices.protocols.ldapconnection.beginsendrequest(v=vs.110).aspx ) and passing AddReuest as input to add entries to the Active Directory.
However, the operation is failing with System.DirectoryServices.Protocols.DirectoryOperationException with message The user has insufficient access rights (same error for both network service as well as computer/local system account). But I did add the computer account to the store in Active Directory and granted full permissions on the store. I am not sure what I am missing?
Is it not possible to add/remove entries on active directory even though computer account has granted full permissions? (I thought local system/network service simply pass the computer credentials over network - I have taken quick peek at the following links for reference The difference between the 'Local System' account and the 'Network Service' account? or http://technet.microsoft.com/en-us/library/bb680595.aspx)
Incidentally, please note that as long as I run the service with one of the domain user accounts the operations are passing. And search (read operations) are passing for all the accounts.
You might be mistaking an authentication problem with an authorization problem. Granted, when nothing works, its hard to tell them apart.
The rights you set in AD are probably ok, but you never get there. In the security event log of the computer that hosts the Active Directory, there is probably a access denied for a network logon of \\server_a. On the Active Directory server, give the computer account (SERVER_A) the privilege "Access this computer from the network".
It will solve the authentication part, letting the process acquire an access token that will be used by Active Directory to perform authorization.
If you are in a low volume lab, you can also try to enable Active Directory Diagnostic Logging, with the Security Events registry entry.
I'm going to put this as an answer instead of a comment though I'm not yet sure if it will help.
When approaching permissions issues like this, I tend to think in terms of sets. I'd start by looking at the set of membership provided to your two different test cases, the machine account and service account with something like a powershell script described here: https://stackoverflow.com/a/20410668/44656.
It's possible that your service account has a permission granted via indirect membership that your machine account does not.
If that doesn't shed light on it, you can try enabling auditing on the ActiveDirectory server and looking for the failed access attempts. Usually a failed permission check does a decent job of highlighting why something is being denied. Auditing can be configured via global auditing policy and setting SACLs on specific object(s) you are interested in.
I have written a windows service that needs to be installed on any flavor of windows from WinXP SP2 on up (client requirement). I initially wrote the service to be started by the SCM during install, using the 'Network Service' account. All testing took place on virtual box VM's in various locations at our site, with no problems during the install, and the service running as expected.
But at the customer site, using VPC's the install of this service fails with Error 1920- a permissions error. It also fails for Virtual Box VM's- in fact it fails for pretty much -every- machine I (and my team) have tried it on but only at the customer QA site.
If the service is manually installed and a local user account is used to log on (a Workgroup account) the service starts fine- so unrealistic as this is, it at least shows the service can run, with the right log on configuration.
I set up a new user account, and went through permissions, local security policies, groups etc to make sure the account that worked and the new one matched exactly, but that new user account also could not start the service(!?). Since the account that worked is a member of a workgroup rather than a domain, I dont think there is a domain policy messing with things, but Im not 100% about that.
Any ideas on what to look for or what I could be missing?
You may want to add the login which is used for running the service to be part of Administrators Group.
Please refer to this Microsoft Support Article
I have a WCF service written in C# being hosted on a remote machine, running as the local administrator account. From my machine logged in as an active directory user, I am sending a command that simply tells it to open a file on the network. I have access to the file, but the administrator account on the host machine does not. I'm using the [OperationBehavior(Impersonation=ImpersonationOption.Required)] meta tag on the method that requires impersonation, and I have the credential type and security modes set correctly. I can verify that account is indeed trying to be impersonated by comparing Windows Identities, but I still get an access denied exception. I'm thinking it has something to do with active directory not authenticating the impersonated user. Is there something I'm missing?
You are entering the domain of Kerberos security and two hops-authentication.
You have two options:
Take the red pill: try to get the two hops-authentication to work. Make sure you have at least a Windows Server 2003 domain, time properly synchronized between all machines and setup proper delegation for the spefic users/computer accounts. If you're really "lucky" you'll have to configure SPNs with SetSPN.
Take the blue pill: forget two hops-authentication, impersonate the WCF service under an account that has just enough rights, and check authorization in an earlier step.
Forgive my frustration, but I do think that my brief experience with this topic has cost me at least 10 years of my life. I hate to see that happend to anyone else. Anyways, this post should give you enough Google keywords if you're feeling brave.
Eventlog and network monitor are useful for debugging...
You also probably need to set up delegation from the web server to the file server. This will allow the file server to trust credentials that the web server has validated. See this MSDN article on how to set up delegation for your application, particularly the section on configuring AD.