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
Related
Scenario:
I have a Windows service written in C# that runs on SERVER1 as domain user mydomain\serviceacct.
The user mydomain\serviceacct is a member of the AD Security Group MySharedFolderAccess
The AD group MySharedFolderAccess has read/write privileges on the shared network path \SERVER2\data (and all data in sub-folders)
The share has granted read/write access to "Everyone"
The service is still getting access denied to the network share
Some more background:
The service in question used to run under an account that had domain admin privileges (this is what I am trying to fix). Unsurprisingly, it worked fine.
The service account was added to the MySharedFolderAccess group after we setup the service login details (although the machine has been rebooted since). At first, I thought it was an AD propagation problem, but this has been going on for several days now.
We have never logged into a machine using the service account (not sure that is relevant
I could grant the service user mydomain\serviceacct, direct read/write privileges to the shared folder. The trouble is that the folder in question is massive and recursively setting access to a single user takes hours - I can't even guarantee it will work.
I am not the author of the C# code, but will be happy to pass along any suggestions that might involve a code change.
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
I am implementing a C# MVC 4 application hosted in IIS 7.5 to replace the company intranet. The requirement is that when a user is at their personal workstation logged in with their windows credentials they will not be prompted to login(this is not optional the customer is firm on this as they believe this is how SharePoint works. Though I cannot confirm), however when they are on a mobile device or on a personal computer off the local network they will be promoted for their credentials. Also, while off the network the user should be able to log out, and the application should log out automatically after a period of inactivity. All users who have access to the application will have AD credentials.
I attempted to get a working solution with windows authentication, but it is my understanding that windows authentication is not intended for use outside a local network. Even if I could get the desired authentication results with this option there is no ability to log out without a significant amount of kludge and hacking with JS.
It appears that by default forms authentication is the answer, but is there a way to utilize the users windows credentials and authenticate against active directory with those without prompting the user to login while on the network?
Unfortunately even after I called Microsoft I was unable to find a good work around for this issue. They did suggest Active Directory Federation Service. This was not an option for us.
There is also a great blog post that does the opposite of what I am looking for but could probably be manipulated to work.
After working with my product owner we settled on a true forms authentication model. The way I was able to appease them was for users on the local network I am setting the time out for the forms authentication token and cookie to a longer duration and refreshing the duration so that if users are active on the application often enough they may never be prompted to log in.
This may not be the most elegant solution, but it has allowed us to meet the requirements set by the product owner. If anyone has additional suggestions I would love to hear them.
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 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.