I AM the system administrator. Who do I call?
Windows Admin
PPTP VPN & Citrix client drive mapping fails behind belkin router
Jul 5th
I came across this today. I’m not sure what’s causing it or how to fix it and probably won’t get a chance to dig any deeper but thought I’d comment anyway.
A Citrix web client sitting behind a Belkin F5D8635 wireless/ADSL router doesn’t get his local client drives mapped in his session. This is seen with several Citrix client versions, server version MPS 4.0 an 4.5.
This has been observed on two separate Belkin routers of the same model.
I’ve also noticed that trying to establish a Microsoft PPTP VPN connection from a client behind this router also fails.
* Update *
Belkin has now has a pre-release firmware which they say fixes the PPTP problem. I haven’t tested it yet so can’t confirm whether it fixes the Citrix drive mapping issue.
ISA Server 2006 Slow Login with LDAP Authentication
May 19th
This one had dogged me for ages. There are a number of possible solutions out there but none helped my situation. Today I finally cracked it!
Here’s the situation:
- ISA 2006 standard edition in a perimeter network
- Published HTTPS apps (MOSS 2007 + other misc ASP.NET apps)
- Weblistener with forms based authentication configured to use LDAP with secure connection and without GC
- Internal CA used to provision certs to domain controllers
- Password management features enabled (Hence the requirement for secure connection and no GC)
When users login they get a delay of up to a minute before the authentication screen disappears and their application begins to load. I did some traffic dumps and found that this delay was occurring during the TLS handshake between the ISA server and the LDAP server (domain controller).
Immediately after the LDAP server issues the “Server Hello” there would be a delay, or what appeared to be some kind of a time-out, of about 15 seconds. This occurred several times throughout the authentication process which resulted in the long delay. I confirmed this by disabling the secure connection to the domain controller. This got rid of the delay but of course this wasn’t an option because without SSL you can’t have password management features enabled.
After much digging I eventually ran process monitor on the ISA server and found that there was a RSA machine key which the firewall service (wspsrv.exe) was trying to access which it didn’t have permission to.
C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys
Every time it tried to read the key it introduced a few seconds delay as can be seen in the time column above.
The solution: Give the NETWORK SERVICE account read access on that file (not the whole folder). Of course the file name will be different for each installation so you’ll need to use ProcessMon to find out which file can’t be read by wspsrv.exe.
So this raises a few questions for me, some easier to answer than others:
- How, when and why are these machine keys are used? *update* These are private keys for certificates installed on the server. They are used to encrypt data which is later decrypted using a public key. They are called “machine keys” because they are for the local “machine” account, as opposed to a user account who’s keys would be under C:\documents and settings\username\…
- How and by what are these machine keys created? *update* When you create or import a certificate e.g Public certificate for SSL web publishing.
- Is there a specific key associated with an application? *update* The private key is associated with a certificate. Use FindPrivateKey.exe to help you match keys to certificates
- Why doesn’t ISA server set the correct permission on the machine key file during installation? *update* Not really an ISA fault – ISA runs as NETWORK SERVICE so if that doesn’t have access neither does ISA. I’m still not sure how the permissions get messed up.
- Why doesn’t ISA throw an error to the event log when it couldn’t read the file?
- Why does everything still work even though it can’t read the file! (albeit with significant delay)?
Any input would be much appreciated!
Thanks for reading.
ISA Not Enough Memory (0×80070008)
Feb 17th
I came across this one today when one of our web apps in the perimeter network stopped working for external users after a switch failure on our internal network.
We run split DNS so if you ask an internal DNS server for the IP address of webapp.ourdomain.com it will tell you the private address of the perimeter webserver but if you ask a DNS server on the internet you will get the public address which is NAT’d to the ISA server which publishes the app. Now if you ask a DNS server in the perimeter network he will forward the DNS request to an internal DNS server. If the internal DNS server is unavaliable the perimeter server will use recursion to resolve the address and ultimatily end up resolving and caching the public address of the webapp. By now you can probably guess what happens.
- Internet user connects webapp.ourdomain.com which is resolved to 203.271.47.15
- The connection is NAT’d by our external hardware firewall and received by the ISA web listener / publishing rule.
- The ISA server resolves the name in the “To” section of the web publishing rule using a perimeter DNS server. The address is from the internal domain (ourdomain.com) so the perimeter DNS server tries to forward the request to an internal DNS server, this fails so the perimeter DNS server uses recursion to resolve the name and returns the public internet address instead of the private address of the web server in the perimeter network. We now have a loop which results on the above error being logged.
There are a couple of ways to deal with this.
- Disable recursion on the domain forwarding in the DNS server settings:
- Explicitly specify the IP address in the “To” section of the publishing rule.
Another one of those “Only in this exact and unlikely situation” type posts but oh well!
MOSS Split Back-to-Back in the Real World
Feb 1st
I’ve realised that I’m just not going to have time to complete my MOSS back-to-back series in the way I started out in Part 1 so instead I’m going to combine everything in a single post based around my original documentation and go from there. Please feel free to ask questions, I’ll answer them to the best of my ability and continue to add detail to this post.
I found the Microsoft SharePoint extranet deployment documentation pretty lacking; from what I could find they don’t go much further than: “here are a few ideas, have fun!” Well I did have fun! And as always with these things the devil is in the details.
Objectives
Primary objective – Making SharePoint available over the internet
- A single URL for external users and internal corporate staff regardless of where they access SharePoint from
- External member accounts contained in a separate domain to internal corporate staff accounts
- Access secured with publicly trusted SSL certificate
- Full backend access and functionality for corporate staff
Secondary Objectives
- Implement single sign-on, forms based authentication and reverse proxy for all web-based applications hosted in the perimeter network
Guiding Principals
- Internal users logged on to internal workstations are seamlessly authenticated to the MOSS site
- Internal users accessing the MOSS site from the internet are presented with a forms-based logon screen; they authenticate using the same username and password as they do for internal workstation logon
- The same URL is used whether the MOSS site is accessed from internal network or the internet
- Perimeter (non-staff) users access the MOSS site from the internet using an account from the perimeter domain
- Perimeter users cannot logon on to an internal workstations and cannot access internal resources.
- Both internal and perimeter users access the same MOSS site
- Both internal and perimeter users can reset their password from the forms-based logon page
- Once users have logged on they can navigate to other applications without having to enter their username and password again.
- The perimeter domain trusts the internal domain
- The internal domain does not trust the perimeter domain
- MOSS WFE applications in the perimeter can use Kerberos to delegate credentials of internal users to other applications on the internal domain, so internal users have access to all the same resources regardless of whether they are access from the internet or from an internal workstation
Solution Overview
The solution is built on a back-to-back firewall topology, it uses forms based pre-authentication and server publishing technologies available in Microsoft’s ISA Server 2006. While the hardware firewall is the first point of entry from the internet the MS ISA firewall in the perimeter network should be considered the “front firewall” as it deals with server publishing and user authentication.
From a MOSS 2007 point of view the Microsoft Split back-to-back topology scenario has been followed; MOSS web front-end servers are located in the perimeter network while the application and database servers reside in the internal network.
A one-way Active Directory trust exists between the perimeter domain and the internal domain. This is a non-transitive trust where the perimeter domain trusts the internal domain but not the inverse. This serves two main purposes; it allows windows authentication and delegation to occur between services in the perimeter domain and the internal domain and at the same time protects sensitive data such as payroll databases on the internal network.
The existing internal network
Forest with 2 domains:
- corpforest.com (empty forest root domain)
- corp.com (internal production domain, contains accounts for all corprate staff)
The new perimeter network
Forest with a single domain:
- perimeter.corp.local (perimeter production domain, contains accounts for all members and external collaborators)
- Authenticates users from both perimeter domain and internal domain via domain trust
Authentication
Identity and Single Sign On
Everyone who accesses applications in the perimeter falls in to one of the two following categories; these categories determine which domain the user account is created in.
Internal Corporate Staff:
Users that require access to perimeter applications such as SharePoint but also require access to internal resources/applications such as Citrix, payroll / finance databases, and Exchange Email. These users reside in the current corp.com domain
Members:
Users that require access to perimeter applications such as SharePoint but do not require access to internal resources/applications. These users will reside in the new perimeter domain (perimeter.corp.local). External vendors / collaborators also fall in to this category
The ISA server in the perimeter domain is configured to support single-sign-on of users accessing applications on the corp.com DNS name space. This means that a user who logs in to one application will be able to follow a link to another without having to re-authenticate. E.g. A user logs on once to sharepoint.corp.com and can then hop to outlook.corp.com then to citrix.corp.com all without having to re-enter their username/password.
Forms Based User Authentication
Users who access web applications from the internet must first authenticate at the front MS ISA firewall. When a user attempts to access a web application (e.g. SharePoint – https://sharepoint.corp.com) in the perimeter network he will first be presented with a forms based (HTML username/password) authentication page at the ISA server. At this point the user can enter a credential from either the perimeter domain or from the internal domain. Once the user’s identity is validated the ISA server will proxy the application to his browser.
Authentication Protocols
The diagram below outlines the steps taken to authenticate and or delegate user credentials. Basic authentication is used from the ISA server to the published destination IIS server. This is done because cross forest Kerberos delegation is not supported by ISA server. Even though the IIS server is a member of the same domain as the ISA server, the IIS application pool is running under a service account from the internal domain, which is done to facilitate windows authentication from the application to the backend database server on the internal network.
The basic credentials are secured using SSL between the ISA server and the destination server.
Once the basic credentials reach the published IIS server it will use Kerberos to authenticate the user against the appropriate domain. Using Kerberos at this stage means that user’s credentials can be delegated to a backend server e.g. SQL Server Reporting Services. The result is that internal users get exactly same experience outside the network as they do inside.
Internal User
- Username / Password from browser sent in clear text (over https) (FBA)
- ISA pre-authenticates user with internal DC via using LDAPS
- ISA delegates basic credentials (over https) to MOSS IIS server
- MOSS IIS authenticates user using Kerberos to internal DC
- MOSS IIS server delegates Kerberos authentication and impersonates user
Member
- Username / Password from browser sent in clear text (over https) (FBA)
- ISA authenticates user with perimeter DC via LDAPS
- ISA delegates basic credentials (over https) to MOSS IIS server
- MOSS IIS authenticates user using Kerberos to perimeter DC
- Delegation fails due to one-way trust. Internal domain doesn’t trust perimeter domain
Configuration
Network Configuration
Networks
Internal : 192.168.33.0/24
Perimeter : 172.16.0.0/16
DMZ : 10.1.1.0/8
Public : 258.17.84.128/28
Network relationships
As shown in the diagram a route relationship is defined between the perimeter and internal network instead of a NAT relationship, this is required to facilitate the domain trust relationship and Kerberos authentication between the two domains.
Routing
All perimeter servers specify the front firewall (ISA02) as their default route
To maximize routing efficiency a persistent static route from the perimeter network to the internal network via the back firewall (ISA01) is added to all perimeter servers. The following command is run during initial server build.
route add 192.168.0.0 mask 255.255.0.0 172.16.1.1 –p
IP Addresses
HW Firewall Internal IF : 10.1.1.254
ISA01 External IF : 10.10.1.1
ISA01 Perimeter IF: 172.16.1.254
ISA02 Perimeter IF : 172.16.1.1
ISA02 Internal IF : 192.168.33.254
WFEVIP1 (SharePoint WFE farm load balanced virtual IP): 172.16.1.50
Network Address Translation
Public access from the internet is NAT’d via the hardwre firewall. The diagram below shows the complete network path taken by a user when accessing the a web app from the Internet. Note the web listener listens on multiple IP addresses. Multiple web publishhing rules use this web listener.
Back Firewall
Firewall Policy
This following table shows the firewall policy on the back firewall (ISA02) that relates to communication between the internal network and the new perimeter network e.g. MOSS frontend/backend/database access. Kerberos, LDAP etc.
This represents the bare minimum of rules as they relate to this document, you’ll certainly have your own additional rules.
Click for an MS Word Version
Front Firewall
Web Publishing Rule Configuration
A single ISA SharePoint publishing rule is used to publish the load balanced MOSS web front end servers. Configuration can be considered default as per the MS ISA SharePoint publishing rule unless detailed below.
Destination server (To)
The FQDN of SharePoint (sharepoint.corp.com) is specified; this resolves to 172.16.1.50 which is the virtual IP address of the load balanced cluster of MOSS WFE servers. We choose to forward the original host header since the internal and external names are the same. Requests must appear to come from the original client otherwise load balancing based on IP address won’t work.
Listener
The listener selected (Perimeter Web Listener) is used by all FBA based applications in the perimeter network; this enables SSO functionality.
Public Name
The public DNS name used to match the publishing rule.
Bridging
Connections to the internal servers are only made via SSL, and on the default port (443).
Authentication Delegation
Credentials are delegated to the target server using basic authentication. Detailed information on why basic delegation is used can be found in the Authentication Protocols section under Solution Overview.
Web Listener / Pre-authentication
This section describes the ISA https web listener and forms based authentication configuration. ISA 2006 web listener defaults should be assumed unless described below.
Networks
All IP addresses that the web listener will listen on are selected here. There is a separate address defined for each application that makes use of this web listener. Traffic is NAT’d by the hardware firewall from public IP addresses to these DMZ addresses. e.g. the public IP address resolved by sharepoint.corp.com is 258.17.84.142 and is NAT’d to 10.1.1.142
Certificates and SSO
An individual certificate is assigned to each application’s DMZ IP address. This allows multiple SSL secured applications to use the same web listener which consequently means that single sign on can be used across all these applications.
Single sign on is enabled for applications on the corp.com DNS suffix.
Connections
http is redirected to https. The good thing here is that http links that that get emailed around when people are working at the office also work when they access from the internet.
Forms
The path to the customised html logon form is specified here as well as the options to allow users to change their passwords and password expiration warning.
Authentication
When users first request an application that is using this web listener they must first be authenticated by the MS ISA server before they are allowed to proceed to the requested application. HTML forms based authentication is used for this initial step. This is where user enters their username and password.
As shown in the screenshot LDAP is used instead of native windows authentication; this is due to an issue with password changes in a cross domain scenario. During testing it was discovered that when using Windows authentication it is not possible for a user to change their password at the HTML logon page if their account is in a different domain to the ISA server. This is problematic especially for seldom used accounts where the password expires or for new accounts where the administrator needs to force the user to change their password at next logon. Microsoft ISA 2006 SP1 introduces a bug which also affects the change password functionality when using LDAP authentication, a non-public patch has been released to fix this bug; for details see the known issues section of this document.
Two LDAP server sets are used, one for the perimeter domain controllers and one for internal domain controllers.
Logon expressions are mapped to the LDAP server sets. How users prefix their username determines which LDAP server set is used to authenticate them. The following config uses “*” wild card to allow the concept of a default domain. If the login starts with “corp\” then the internal LDAP set is used other wise it default to the perimeter set. This means that anyone who has an account in the perimeter domain doesn’t need to specify a domain.
Two LAP servers (domain controllers) are defined for each LDAP server set. For password change functionality to work, a secure connection must be used (LDAPS) and the “Use Global Catalog” option must be turned off. A lookup account in the target domain must also be made available for the ISA server. This is a non-privileged account with a very strong, non-expiring, set/forget password which is set during configuration.
A secure SSL LDAP connection requires that port 636 be open to the internal domain controllers on the back firewall, this is noted under the “back firewall” configuration earlier in this document.
A server certificates must also be installed on the domain controllers and must be trusted by the ISA server. This can be acheived by setting up a CA (certiificate Authority) but that’s out of scope for this post.
I will however point out a good tip for testing that the ISA server is correctly trusting the DC and is able to make an LDAPS connection. Use the ldp.exe tool from the Windows Server 2003 resource kit and make a connection on port 636 with SSL enabled. If everything is working correctly then it will connect without error otherwise it will throw some kind of TLS error.
Active Directory Trust Configuration
A one-way domain trust is configured between the corp.com domain and the perimeter.corp.local domain. This is done to allow internal accounts to be used in the perimeter domain which inturn enables windows authentication to be used when accessing backend resources such as SQL databases. This trust means that deploying MOSS web front end servers is as straight forward as adding the web front end role, all IIS configuration is completed by MOSS and remains valid in both the internal and perimeter domains.
Now you might be wondering why we don’t use a forest trust. Well the truth is I had issues with using a forest trust and if anyone can shed any light on this I’d be very interested. I’d love to set this back up in the lab but I can’t see my self getting time.
Here’s the situation. On the internal side we have an empty forest root domain of corpforest.com inside that forest we have the internal production domain called corp.com. On the perimeter we have a single forest/domain called perimeter.corp.local. We create a one-way forest trust (which is transitive) between corpforest.com and perimeter.corp.local. We then take a member server in the perimeter.corp.local domain install MOSS and join it as a webfront end to the MOSS farm based in the internal network. This will automatically create IIS MOSS web apps and application pools. These application pools are set up identically to the ones on the internal MOSS servers so of course are configured to run under internal service accounts.
Everything seems to be working correctly the application pools run fine but when trying to browse to the site IIS writes an error: “The caller is not the owner of the desired credentials”. Despite many hours of digging through logs, traffic sniffing and bashing my head against the desk I was unable to get IIS to work with a service account from another domain when using the forest trust, except if I used an account from the root domain of the trusted forest which is not ideal as all internal MOSS IIS servers would need to be re-configured. I should mention that this is not an issue specific to MOSS, it’s an IIS issue in general. I stood up another IIS/ASP.NET/Visual Studio test box in the perimeter and it had the same problem.
If both your internal and perimeter domains are single forest/domain I expect you might not have any issues and I’d be very interested to hear your results.
SharePoint
This section only describes MOSS configuration that relates to the perimeter network deployment.
People Picker
To enable the “PeoplePicker” in a one-way trust scenario to search both domains (perimeter and internal) the following stsadm commands must be run.
On all servers in the farm:
stsadm -o setapppassword -password “(password)”
(Where “password” is a strong password shared between the servers.
On all web front end servers:
stsadm -o setproperty -url http://sharepoint -pn
"peoplepicker-searchadforests"
-pv "domain:perimeter.corp.local",
PERIMETER\PeoplePickerService, (Password)
(Where “Password” is the password for the unprivileged service account “PeoplePickerService” used to perform lookups on the perimeter domain)
AAM (Alternate Access Mappings)
Zones
The following access mappings / zones are configured
Internet users only access sharepoint over SSL in the default zone via https://sharepoint.corp.com
Internal users access sharepoint over plain http in the intranet zone via http://sharepoint.corp.com. This is the default home page for all internal users as set by group policy. Plain HTTP is used for internal users to ensure optimum performance especially across the WAN where the Certeon accelerators are deployed. The URL http://sharepoint is also valid for internal users.
Some SQL Server Reporting Services (SharePoint Integrated Mode) features only work when accessed in the default zone hence internal users wanting to access these features will need to access sharepoint in the default zone via https://sharepoint.corp.com. See the known issues section for more information.
Known Issues
MS ISA Forms Based Password Changes
Valid Account Discovery Vulnerability
A patch in ISA 2006 SP1, as means to fix a security vulnerability broke password change functionality when using LDAP authentication. (http://support.microsoft.com/kb/957859/). This has been fixed by non-public patch KB959357 (http://support.microsoft.com/kb/959357). Unfortunately this patch re-introduces the security vulnerability. This Vulnerability means that when an incorrect password is entered for a valid account and the account is in a password-expired state, a change password form is displayed; while the correct old password must be specified before a new one can be set this could allow an attacker to discover that an account name is valid by brute force. This can be considered a low risk vulnerability which is out weighed by the need to allow users to change their own password. Hopefully Microsoft will fix this issue in the next major service pack. Below is a summery of the vulnerability behaviour.
Password length / Complexity Policy
When a password is changed using the ISA FBA change password tool the password complexity is checked against the domain that the ISA server is a member of. This means that both the internal and perimeter domains must have the same password complexity / length requirements to ensure consistent behaviour for end users. -I need to confirm this one!
SSRS in SharePoint Default Zone Only
When using SQL Server Reporting Services in SharePoint integrated mode some methods of viewing reports are only supported in the default zone. For example, if you try to open a report from a document library while accessing the sharepoint on http://sharepoint.corp.com (intranet zone) instead of https://sharepoint.corp.com (default zone) you will be presented with the following error.
The specified path refers to a SharePoint zone that is not supported.
The default zone path must be used.
The report viewer webpart works correctly regardless of what zone it is accessed in.
|
Step |
St John Internal WAN User |
St John Member |
|
1 |
Username / Password from browser sent in clear text (over https) (FBA) |
Username / Password from browser sent in clear text (over https) (FBA) |
|
2 |
ISA pre-authenticates user with St John DC via the domain trust |
ISA authenticates user with perimeter DC |
|
3 |
ISA delegates basic credentials (over https) to MOSS IIS server |
ISA delegates basic credentials (over https) to MOSS IIS server |
|
4 |
MOSS IIS authenticates user using Kerberos to St John DC via forest trust |
MOSS IIS authenticates user using Kerberos to perimeter DC |
|
5 |
MOSS IIS server delegates Kerberos authentication and impersonates user |
Delegation fails due to one-way trust. Perimeter trusts STJOHN only. |
RDP through a firewall fails with: “The RPC server is unavaliable”
Jul 1st
This is just a quick one…
When trying to logon to Windows server 2003 via remote desktop you receive the following message:
The system cannot log you on due to the following error:
The RPC server is unavailable.
Please try again or consult your system administrator.
You will also receive the following event in the target server’s application event log:
Event ID: 1219
Logon rejected for Domain\User. Unable to obtain Terminal Server User Configuration. Error: The RPC server is unavailable.
There are a number of reasons you might see this message but in my case it was because the server I was connecting to was behind a firewall and in different domain to the one which my account was in.
When you logon via RDP, “Terminal Services” will contact the domain which your account is in to query terminal services information about your account e.g. profile path. It does this using RPC to a domain controller.
In my case the server concerned was in the perimeter network and there was no way I was going open RPC on the firewall to allow it to talk to an internal DC. And since the purpose for RDP to this server was purely for administration I really didn’t care if it couldn’t get my profile info from AD.
Fortunately there is a workaround as described in this Microsoft article, actually the article refers to a different problem, but the workaround is the same.
http://support.microsoft.com/kb/815266
- Locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server - Create a new DWORD called IgnoreRegUserConfigErrors
- Give it a value of 1
Done! I might consider creating a group policy preference to implement this across all the servers in the perimeter domain.
Active Directory and Kerberos SPNs Made Easy!
Apr 7th
There are a lot of articles out there on setting up Kerberos Service Principal Names but today I’m going to make it simple. Bear with me as I start off with the basics; by the end of the post it will all be very clear.
Throughout this post I’ll make reference to a scenario of a client computer connecting to an SQL server called sql1.domain.com however the same applies for any service, for example a web server where the client connects via HTTP.
The SQL server service is running under a domain service account called “domain\SQLSVC“. No SPNs have been set yet.
The Basics
Active directory user and computer accounts are objects in the active directory database. These objects have attributes. Attributes like Name and Description.
Computer and User accounts are actually very similar in the way they operate on a Windows domain and they both share an attribute called ServicePrincipalName. An account object can have multiple ServicePrincipalName attributes defined.
The setspn.exe tool manipulates this attribute. That’s all it does.
The Failure
The client wants to access the SQL server so he asks his domain controller: “Please may I have a ticket for accessing MSSQLSvc/sql1.domain.com”
Now the domain controller asks the active directory database: “Give me the name of the account object who’s ServicePrincipalName is MSSQLSvc/sql1.domain.com“
The active directory database replies: “Sorry, there are no account objects with that ServicePrincipalName”
So the domain controller asks the active directory database again: “Ok then, give me the account object who’s ServicePrincipalName is HOST/sql1.domain.com“
All computer accounts have, by default ServicePinciaplName attributes set to:
HOST/[computername] and HOST/[computername].[domain]
So the active directory database replies to the domain controller: “The account object that has that ServicePrincipalName is sql1.domain.com’s computer account“
The domain controller now creates a ticket that only the computer account of sql1.domain.com can read. He gives the ticket to the client.
The client goes to the SQL service on sql1.domain.com and says “here is my ticket, may I come in?”
The SQL service will attempt to read the ticket. The problem is, the SQL service is not running under the computer account; it is running under a domain service account. It can not read the ticket; the ticket is only intended for the computer account of sql1.domain.com. Authentication fails (falls backto NTLM).
The Fix
Now lets run the setspn.exe tool to manipulate the ServicePrincipalName attribute of the SQL service account.
setspn -a MSSQLSvc/sql1.domain.com domain\SQLSVC
We will also add sql1 (without the domain name) in case we want to access the the server without the domain name appended.
setspn -a MSSQLSvc/sql1 domain\SQLSVC
Now run through the scenario again and this time notice that the domain controller will return a ticket that the SQL server service account can read.
Obviously this is heavily paraphrased but hopefully it helps you understand the reason for setting the SPN attribute on the account that runs a given service. Of course if the service runs under the local NetworkService or LocalSystem account then everything will just work because these local accounts represent the computer account in active directory.
MOSS 2007 SSRS WMI provider error
Mar 22nd
Setting up SQL Server Reporting Services in SharePoint integration mode and you turn up with this error when you try to “Grant Database Access” from within Central Administration:
“Unable to connect to the Report Server WMI provider“
If you’ve got an ISA firewall between your MOSS central admin and your SSRS server you’ll need to turn off “Strict RPC Compliance” just while central admin performs the “Grant Database Access” operation .
Hope this saves someone some time. Not a very common scenario I guess.
IE GPO Zone Templates and the “Open File – Security Warning”
Feb 9th
Since you’re reading this you probably already know that Internet Explorer has a number of security zones. URLs are treated differently depending on the zone they fall into. These security zones apply not just to URLs in Internet Explorer but to windows in general e.g. accessing files from a network location. My specific problem was a GPO start-up script that ran backinfo to display the server info on the desktop when an admin user logs on. Backinfo.exe an unsigned application stored on the netlogon share would throw the Open File – Security Warning every time it was launched. More about that soon.
In the enterprise it’s desirable to configure all these zone and security settings using group policy but there are a few gotchas that can make the configuration and testing process a bit confusing.
A standard zone template can be applied to a user’s settings. After you apply this template you can do a gpupdate /force/target:user; you won’t get a warning about logging on/off. Now in Internet Explorer you’ll notice a couple of things. (1)The security level and visual slider for the zone on the security page will not have changed and will not reflect the template you’ve selected in the GPO. (2)If you click on “Custom level” you’ll see that the individual settings that the selected template represents are in fact set and are now unchangeable, i.e. the policy has applied.
Ok so at this point we could be forgiven for assuming that the policy has been fully applied to the system; we can see the changes in IE and we know that gpupadte didn’t ask us to log off/on.
Now on to the “Open File – Security Warning “, this is affected by the setting pictured above, “Launching applications and unsafe files”. Since this is a trusted zone we trust all the locations in this zone so we are happy to launch unsigned applications without a security warning. For some strange reason this setting is one of the only ones that can’t be set individually with group policy, the only way to set it (via GPO) is to apply a template as described above. Both “Low” and “Medium Low” will allow applications to launch from a network location without a security warning.
The thing that’s really confusing is that even though doing the gpupdate updates the policy in IE it is not fully applied to the reset of the system until you log off/on.
In Conclusion
- Security templates are not visually reflected in the security page of Internet Explorer even though they are applied.
- Security zone settings are applied to Internet Explorer by doing a gpupdate but a log off/on is required to apply these settings to the rest of the OS
- The “Launching applications and unsafe files” setting determines whether the “Open File – Security Warning” dialog is displayed when launching applications from a given location
- The “Launching applications and unsafe files” cannot be set with a an indvidual GPO setting. (You could create a custom adm file though)
- When setting zone security via GPO I recommend making the Internet Explorer security page invisible to users to avoid confusion as they can still quite happily adjust the security level slider, it just won’t have any effect!
Deny yourself access to a Group Policy
Mar 9th
When clicking too fast you accidentally denied “Full Control” to “Authenticated Users” for a Group policy you were working on. Since deny takes precedence over allow the results are that you are now denied the ability edit the GPO at all. This includes editing permissions to remove the blundered Access control entry! In the Group Policy management console it Looks like this:
Components of a Group Policy Object
A GPO is made up of two parts; a set of files in sysvol and an Active Directory object. When correcting GPO permissions you must modify the ACL on the AD object using DSACLS (included in the w2k3 support tools) and the sysvol NTFS permission.
The following dsacls command will remove the offending deny ACE from the ACL, in this case “Authenticated Users” from the AD object. The object is named by the GUID that can be seen on the inaccessible object in the GPMC.
dsacls “cn={3EE757FE-B5A4-4D23-937D-A3AF5G7F0CEA}, cn=Policies, cn=System, dc=wordpress, dc=com“ /R “Authenticated Users”
If successful this command will return a full list of the permissions for the object
Next up you need to remove the deny ACE from the policy’s NTFS folder ACL. Again the GUID of the policy is used to name the folder:
\wordpreessSysvolwordpress.comPolicies{3EE757FE-B5A4-4D23-937D-A3AF5G7F0CEA}
At this point your GPO will be accessible within the GPMC and the permissions will be consistent across AD and Sysvol. All that’s left to do is to add “Authenticated Users” back to the GPO. Do this by editing the GPO with the group policy editor; doing so will apply permission changes to both the AD object object and the Sysvol policy folder.
Just thought this might help someone, not that it’s ever happen to me! ;-p