Tuesday, May 11, 2010
How to access an SQL server database on a different Subnet?
For example the Sql server you are trying to access is on a different subnet to the subnet of the machine you are trying to access it from. i.e. SQL Server A: 192.168.1.2 and SQL Server B: 192.168.2.2. To access SQL Server B from SQL Server A the connection string will be TCP:192.168.2.2,1433
Thursday, March 25, 2010
Kerberos Authentication issue on IIS7
Problem
I have been pulling my hair out trying to resolve get Kerberos and MOSS to work on IIS7. The problem that I have been having is that every time is I configure SPN's correctly i seem to be getting a Security audit log Error that says the below:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
The problem here is that one of the security changes in IIS 7.0 is that Windows Authentication is performed by default in the kernel. Because HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool identity. This means that the creation of an SPN is unnecessary because default SPNs are created when the server is joined to the domain. You can of course change the app pool identity without having to register a SPN, and the app pool account doesn't need to be a domain account. However, it trips up SharePoint as even on a single server SharePoint is currently considered a web farm (should use a domain account). Therefore you need to use the application pool identity for authentication. This is what caused the accounts to fail.
Solution
Make changes to the IIS7 applicationHost file which can be found in C:\Windows\System32\inetsrv\config\
and replace the following line
<windowsauthentication enabled="true">
with
<windowsauthentication enabled="true" useapppoolcredentials="true">
The application pool identity will now be used and the Kerberos issues will be fixed.
I have been pulling my hair out trying to resolve get Kerberos and MOSS to work on IIS7. The problem that I have been having is that every time is I configure SPN's correctly i seem to be getting a Security audit log Error that says the below:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xc000006d
Sub Status: 0xc000006a
The problem here is that one of the security changes in IIS 7.0 is that Windows Authentication is performed by default in the kernel. Because HTTP.sys is handling the authentication, it is by default done under the LocalSystem account regardless of the application pool identity. This means that the creation of an SPN is unnecessary because default SPNs are created when the server is joined to the domain. You can of course change the app pool identity without having to register a SPN, and the app pool account doesn't need to be a domain account. However, it trips up SharePoint as even on a single server SharePoint is currently considered a web farm (should use a domain account). Therefore you need to use the application pool identity for authentication. This is what caused the accounts to fail.
Solution
Make changes to the IIS7 applicationHost file which can be found in C:\Windows\System32\inetsrv\config\
and replace the following line
<windowsauthentication enabled="true">
with
<windowsauthentication enabled="true" useapppoolcredentials="true">
The application pool identity will now be used and the Kerberos issues will be fixed.
Content deployment job 'XXX' failed.The remote upload Web request failed.
During a Sharepoint publishing process I got the following error:
Content deployment job 'XXX' failed.The remote upload Web request failed.
The problem that was occuring was that the account that was being used to authenticate against the central administration of the target server in "Content Deployment Settings" from the source did not have permissions in the destination site collection. I gave that account permissions to the site collection and it worked.
Content deployment job 'XXX' failed.The remote upload Web request failed.
The problem that was occuring was that the account that was being used to authenticate against the central administration of the target server in "Content Deployment Settings" from the source did not have permissions in the destination site collection. I gave that account permissions to the site collection and it worked.
Tuesday, October 20, 2009
Sharepoint 2010
Updates to MSDN with more information on Sharepoint 2010 has been made. Click here....
Tuesday, October 6, 2009
Monday, October 5, 2009
Wednesday, August 5, 2009
Subscribe to:
Posts (Atom)
