I have spent several days trying to get a "managed service account" set up on Windows Server 2012 for a .NET web app. Let's start with the error and work backwards.
I get the following events ever time I try to access a page on the web site where * is the name of my app pool:
Warning 5021 - The identity of application pool * is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.
Warning 5057 - Application pool * has been disabled. Windows Process Activation Service (WAS) did not create a worker process to serve the application pool because the application pool identity is invalid.
Error 5059 - Application pool * has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.
~~~
While standing up a new server, I came across what appears to be an awesome feature which I had not used before:
http://technet.microsoft.com/en-us/library/dd548356%28v=ws.10%29.aspx
Since I am standing up a new app with a new database, this seemed like the perfect opportunity to take this for a drive!
I eventually figured out how to create the managed service account with the following power shell commands on a domain controller:
import-module activedirectory
new-ADServiceAccount -SAMACCOUNTname "SERVICE_ACCT$"
add-adComputerServiceAccount -Identity SERVER_NAME SERVICE_ACCT$
In the same powershell window, I can list services accounts for a given server with this powershell command:
get-ADComputerServiceAccount SERVER_NAME
And my managed service account is there! All good so far ...
I then had to modify our central group policy to include my service account for "Log on as batch job" and "Log on as service". These were under Polices\Windows Settings\Security Settings\Local Policies\User Rights Assignment on our domain controller (these were not editable on the local server as these were being pushed down).
After the changes and a coffee break, the rights show up on my server!
So now I have (1) created a managed service account which has (2) been granted access to a specific server and on that specific server (3) the service account has log on as batch job/service rights. I also (4) gave both the app pool and service account modify access to the web site folder.
I verified the site works with the default AppPoolIdentity account.
And ... I still get the errors above (which I have had during this whole process). I have to be missing something, but I just can find anything else to try!
Regards,
Cooter
I had to put this on the shelf for a while, but was eventually able to get this working. The most helpful resource I found was the following YouTube on MSAs.
http://www.youtube.com/watch?v=VNCGSQPhLuM
To summarize, there are quite a few requirements and steps
Domain Requirements:
Domain Function Level - Windows Server 2008R2+
Run ADPrep/ForestPrep
Client Requirements:
Windows Server 2008R2+
.Net Framework 3.5
Active Directory Module for Windows PowerShell (this gets installed with AD DS, but I was able to excluded all but the module during the process)
Supported Software:
IIS - yes (app pools)
SQL Server - no
On server where MSA is to be used, navigate to Server Manager - Features - Add features
Confirm 3.5 Framework installed
Confirm Active Directory Module for Windows PowerShell installed
On any server with AD administration tools, Via PowerShell: NOTE: My MSA is WorkProdDnnIIS and my host is WorkProd2012.
C:> import-module activedirectory
C:> New-ADServiceAccount -name WorkProdDnnIIS -enable $true
C:> Add-AdComputerServiceAccount -Identity WorkProd2012 -ServiceAccount WorkProdDnnIIS
On any server with AD administration tools, via AD Users and Computers
the new MSA should be listed under "Managed Service Accounts"
On server on which MSA is to be used, via PowerShell
C:> import-module activedirectory
C:> Install-AdServiceAccount -Identity WorkProdDnnIIS
On server on which MSA is to be used, via IIS Manager
Change App Pool identity (e.g. POWER\WorkProdDnnIIS$ - Dollar sign required on end, leave password blank)
Lastly, the local policy settings to allow "Log on as batch job" and "Log on on as service" are required for the MSA for IIS app pools. I would suspect that the Install-ADServiceAccount would do this, however these changes could not be made locally. I manually edited the group policy on a domain controller to achieve the same end result.
Regards,
Cooter
Related
I have a Visual Studio Team Services Build Definition to deploy an Asp.Net MVC application to Azure Web Site. I used the wizards to create my build definition so it is pretty vanilla implementation.
Most of the build goes well. The 'Get Source', 'Build Solution', 'Test Assemblies' tasks all pass. But the task for the 'Azure Deployment' is failing and it looks to me as though it is having problems with the PowerShell credentials.
The error stats :
AADSTS50034: To sign into this application the account must be added to the mydomain.org directory.
Since this is running in the cloud, I don't know what account it is trying to use so I am looking for some ideas how to get past this step.
Here is the output of the Azure Deployment task.
******************************************************************************
Starting task: Azure Deployment: http://superpoolsquares.azurewebsites.net
******************************************************************************
Executing the powershell script: C:\LR\MMS\Services\Mms\TaskAgentProvisioner\Tools\agents\default\tasks\AzureWebPowerShellDeployment\1.0.23\Publish-AzureWebDeployment.ps1
Importing Azure Powershell module.
Importing AzureRM Powershell module.
AzurePSCmdletsVersion= 1.0.0
Get-ServiceEndpoint -Name edb1710a-25b3-4037-93b0-58c00f83c038 -Context Microsoft.TeamFoundation.DistributedTask.Agent.Worker.Common.TaskContext
Username= ********
azureSubscriptionId= b4d2fa61-92ff-494a-9ff1-d1362895fc78
azureSubscriptionName= Visual Studio Professional with MSDN
Add-AzureAccount -Credential $psCredential
AADSTS50034: To sign into this application the account must be added to the mydomain.org directory.
Trace ID: 2cb051b9-6e76-4789-8a5d-e95a9486b731
Correlation ID: 22162659-23fa-4858-b957-9ccbf120654d
Timestamp: 2016-02-10 00:19:27Z: The remote server returned an error: (400) Bad Request.
Add-AzureRMAccount -Credential $psCredential
AADSTS50034: To sign into this application the account must be added to the mydomain.org directory.
Trace ID: ed10284e-87b6-4d45-8bd3-9ed1b25f4498
Correlation ID: 88960dea-0434-4eba-9f17-e4d6ceba1a41
Timestamp: 2016-02-10 00:20:21Z: The remote server returned an error: (400) Bad Request.
There was an error with the Azure credentials used for deployment.
It uses the account you configured on Service Endpoints dialog as following:
According to the error message, the account you use isn't been added to the mydomain.org directory which is the trusted AD by the subscription. So you need to add your account into that directory from Azure Portal and then try the deployment.
If you don't want make any change on Azure. You can use "Certificate Based" authentication when configure the connection.
This seems to be a common question, however I haven't found a solution out there and many related questions are quite vague. Anyways, I am deploying an ASP.NET MVC 5 application to AWS using the AWS toolkit for Visual Studio Pro 2013. I have successfully published the app to Elastic Beanstalk with the exception of my database file which exists as a localDB database (.mdf). In trying to migrate this (very small) database I have created an RDS DB instance for SQL Server Express. My issue is that I cannot create a SQL Server DB which appears to be a common issue for VS users: I right click on the DB instance, select "Create SQL Server Database", VS is busy for a few moments and then nothing happens.
What I have done thus far:
I have an RDS instance created on a VPC with a security group that has an Inbound rule set to allow all traffic from my IP
I have an IAM user account with the following policies: PowerUserAccess, AmazonS3FullAccess, AmazonVPCFullAccess (I imagine some of this is redundant-I added additional policies to see if it was a permission issue)
So to succinctly state my questions, why is Visual Studio failing to create the SQL Server DB within the database instance? Or alternatively, is there a simpler method of migrating my database to AWS?
Just FYI, these are the references I have been using to deploy my application:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_NET.quickstart.html
https://aws.amazon.com/blogs/aws/net-support-for-aws-elastic-beanstalk-amazon-rds-for-sql-server-/
I'm brand new at AWS so let me know if clarification is needed.
Update: I checked the logs for my instance and I'm getting error logs
2014-12-12 18:16:02.72 Server The SQL Server Network Interface library could not register the Service Principal Name (SPN) [ MSSQLSvc/AMAZONA-E3AJMJI ] for the SQL Server service. Windows return code: 0xffffffff, state: 53. Failure to register a SPN might cause integrated authentication to use NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies and if the SPN has not been manually registered.
And
2014-12-12 18:47:23.72 Logon Error: 17806, Severity: 20, State: 14.
2014-12-12 18:47:23.72 Logon SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: 113.108.150.211]
2014-12-12 18:47:23.73 Logon Error: 18452, Severity: 14, State: 1.
2014-12-12 18:47:23.73 Logon Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 113.108.150.211]
UPDATE: Issue solved. We use a proxy server in my office which seemed to cause authentication with the RDS instance to fail, not allowing me to connect from my machine. I accepted Ossman's answer as I think it solves a lot of similar questions I've come across trying to solve this.
This is a AWS explorer for Visual Studio 2013 bug and actually occurs because you're using the "default security group" by default when you're creating your DB instance in RDS.
Access the EC2 Service in AWS Management Console.
Click on "Security Groups", and then on "Create Security Group"
Give it a Name, Description and use "vpc-0846aa61" as VPC.
And then add following rule for both "Inbound" and "OutBound" rules
Type: "All traffic"
Source (for Inbound): "Anywhere"
Destination (for Outbound): "Anywhere"
Then Create the Security Group
Go back to your DB Instance and then change the "default" security group to the one you just created. This is done by clicking "Instance Actions" and then "Modify".
Then you should be able to see following window when you right click on your instance in Visual Studio and clicking on "Create SQL Server Database":
My DB Instance:
When I start the application pool, and request a page in an application in that pool, I get a "HTTP Error 503. The service is unavailable."
If I look at the application pools in IIS, I can see that it has now stopped. Going to the event viewer I find this error message:
'The identity of application pool Badge.Web is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights. If the identity is not corrected, the application pool will be disabled when the application pool receives its first request. If batch logon rights are causing the problem, the identity in the IIS configuration store must be changed after rights have been granted before Windows Process Activation Service (WAS) can retry the logon. If the identity remains invalid after the first request for the application pool is processed, the application pool will be disabled. The data field contains the error number.'
I'm very sure the credentials I'm using is correct. Something else is causing the app pool to stop.
I had similar problem today when an application pool using Windows user identity X stopped working after password change for that user.
Apparently, some information linked to old credentials was stored in the system, and I solved the problem by:
switching app pool identity to NetworkService
switching it back to X using the new password
So far it's working fine.
I found an article saying
The fix is to ensure that the Service/AppPool accounts have the ‘Log on as a batch job’ and ‘Log on as a service’ user rights on the server. This right can be found in Local Security Policy > Computer Configuration > Windows Settings > Local Policies > User Rights Assignment. Either remove the conflicting Group Policy and fix the Local Policy or add the rights to the Group Policy.
http://waveformation.com/2009/06/08/event-5021-the-identity-of-application-pool-lsgroupexpapppool-is-invalid/
While there may be several reasons why this may occur, in this specific case, the 503 error was occurring because the Application pool failed to start. This was because the password was changed recently for the Identity under which the application pool was trying to run. Fix was to go to the IIS Manager-> Application Pool -> Advanced Settings -> Process Model -> Identity and set the password to the new one.
It would also help to check the Event Viewer Logs(Event Viewer (Local) -> Windows Logs -> Application to look for specific causes of failure before proceeding to troubleshoot any further.
My problem was solved by changing Application Pool Identity to NetworkService, going to Advanced Settings > Process Model > Identity > NetworkService with the desired Application Pool selected.
I had the same issue and my solution was: Manager -> Application Pool -> "Select the pool" -> Advanced Settings -> Process Model -> Identity -> NetworkService
I am setting up Tridion R 5.3 content Manger server on Win 2003 Server. My Windows server is not having Active directory service enabled. The Impersonation user that I have set in Tridion Configuration Manager is
WORKGROUP\mtsuser
since the 2003 server is not under any Domain. Now whenever I try accessing console on //localhost/ and enter my credentials for mts user. The following error is shown with Mesaage on Console reading as "You dont have permission to access R 5.3 contact Administrator."
Event Type: Warning
Event Source: Kernel
Event Category: Security
Event ID: 200
Date: 2/15/2013
Time: 2:11:23 PM
User: WORKGROUP\mtsuser
Computer: WORKGROUP
Description:
Unable to Initialize TDSE object.
Access is denied for the user WORKGROUP\mtsuser.
Error Code:
0x80040302 (-2147220734)
Call stack:
SystemBLST.GetUserContext
SystemBLST.IBLSecurityST_GetUserContext
TDSE.Initialize
Please help In dire need of a solution....
If your machine is not under domain then where does WORKGROUP\mtsuser come from? Who is managing its credentials? I think you should use local machine name\mtsuser and manage credentials locally. Besides you are not supposed to be able to access CME with MTSUser. This user is system user and is only to be used by the system. Also, as you are on 5.3 version, you should check documentation and make sure you've granted all the necessary rights and permissions to this user.
And you should really consider one of the supported versions of Tridion
MTSUser should not be set as an impersonation user, this is your SYSTEM account
"Access is denied" means literally that the user doesn't have permissions for a given action. Maybe it's not an allowed Tridion user, since you don't have access to Tridion I'd recommend looking at the TRUSTEES table, and finding the MTSUser account there. If it doesn't match, then it certainly will not work. Add a record to the TRUSTEES table with the correct information.
As user978511 states, 5.3 is pretty old (early 2008), and not officially supported anymore, but I doubt you can do anything about that.
The impersonation account should be the same account that runs the application pool in IIS - by default this is Network Service
Is it possible to give asp.net read permission to the certificate store?
If yes , how?
If no... do I need to set the permission manually per certificate file?
If yes where are these files physically on the HDD?
Generally you give permissions to A certificate. I use a method like this to find the custom made cert and grant permissions. If you are using a cert issued by a public entity like Verisign, Thawte, etc, this is probably unnecessary.
FindPrivateKey.exe My LocalMachine –n "CN=<certificate issuer>"
...will find certificates on the local machine in the personal store for a particular issuer.
Note: If FindPrivateKey is not on your local machine,
download the WCF samples, including the FindPrivateKey tool, at
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=21459
FindPrivateKey returns the location of the private key for the certificate, similar to
"C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030".
Run the following command line to assign read only access permissions to the process identity of the ASP.NET/WCF Service
cacls.exe "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys\4d657b73466481beba7b0e1b5781db81_c225a308-d2ad-4e58-91a8-6e87f354b030" /E /G "NT AUTHORITY\NETWORK SERVICE":R
NOTE: If you are running Microsoft Windows® XP, give the certificate permissions for the ASPNET identity instead of the NT Authority\Network Service identity, because the IIS process runs under the ASPNET account in Windows XP.
Certificates are viewable from the MMC snap in for Certificates. Open MMC, choose File --> Add/Remove Snap in, click the add button and choose certificates. From here you will need to choose the appropriate store (usually Computer Account - Local Computer for ASP.NET items) to manage and then you can view/admin the certs.
Please take a good hard look at the different command line options, and make sure that you have a clear understanding of what certificates are and how they work before granting any permissions.
The network service account that asp.net run under by default doesn't have access to the local machine personal certificates. Grant access by the following:
Repost from Sohnee # forums.asp.net
Step 1 - if you don't already have it
installed - get WinHttpCertCfg
Step 2 - if you already have the
certificate installed on the machine
and you just need to grant access to
Network Services:
WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "IssuedToName" -a "NetworkService"
Don't really like answering my own questions, but one simple way to get rid of this error is just to give network service full access to the c:\drive, and propagate permissions down.
You'll shoot me down I know, telling me how bad this is - but it works.