Delegating read only access to Domain Controller Event Logs


Something AD administrators used to dread was the inevitable request for access to Domain Controller event logs for monitoring purposes.

The lazy admin (Rob Field) approach was to give the service account Domain Admins. More dedicated staff would fiddle around with the SDDL security descriptors until they got it right.

Well that’s not needed anymore… Delegating read only permission to the event logs cannot be easier with 2008.

There is an Active Directory built-in group called ‘Event Log Readers’. All you need to do is drop the service account that needs this privilege into the Event Log Readers group and your monitoring software should be happy.

Note this gives access to all event logs. However if you do not want to give them access to all event logs you still have to resort to using SDDL. There is a good post here.

This also works with Member Servers. Just drop the service accounts into the Event Log Readers group on each member server.

Advertisements

UAG – Top 10 Things to do after you’ve installed it


The UAG needs a lot of tweaking after you’ve installed it, here is a list of my top 10 things to do to get started:

  1. Make sure you have SP1 update 1 installed – KB2585140.
  2. If something is not working (like a Remote Desktop link), run the Best Practice Analyser. This will highlight any issues, like certificate errors that are stopping the application from working.
  3. Increase the default session timeouts – ‘Inactive session timeout=300 seconds’ and ‘Trigger automatic logoff after 60 mins’. Way to low for most environments. Increase to suit yours.
  4. Enable access for mobile users – This is disabled by default.
  5. Customise your portal – Not easy to do, but the sooner you brand it the better.
  6. Integrate with a two factor authentication product to increase security.
  7. When adding Active Directory integration update the search root and scope to include the domain only, i.e. the root, enable subfolders and leave nested groups blank so every group in the domain is queried. Takes longer but less hassle for Ops teams.
  8. Once you have configured authorisation don’t move the groups to another OU in Active Directory or your authorisation will break.
  9. To clean up the logon page, remove the language bar, deselect ‘Enable users to select a language’ from the Authentication -> Trunk configuration settings.
  10. Update the language files to customise all the logon and portal text.

And 1 to remember!

  1. If you are going to modify your Login.asp file make sure when you update the user logon page fields you do NOT use a leading forward slash, e.g. ‘/CustomUpdate/Login.asp’ is incorrect. The correct format is ‘/CustomUpdate/Login.asp’. Read a full outline here

Updates:

  1. Check the protocols and encryption available via the best  public website checker – http://ssllabs.com
  2. Install JVM for web monitor in IE – http://java.com/en/download/manual.jsp
  3. Disable TCP chimney, Receive Side Scaling and Taskoffload to resolve client endpoint issues as per this post:

 

Active Directory Domain Controllers and VMware Tools Shared Folders. Grrrrrrr


Don’t you wish there was an easier way to discover faults? Rather than (what seems like) continuously wasting hours of the day figuring out problems… Software should be more intelligent… For instance running dcdiag and getting ‘RPC replication errors’ should be reported as ‘RPC replication errors due to VMware Tools Shared Folders’ would save everyone a lot of time…. This leads me to my next post.

I had an issue recently where I was trying to create a domain trust between two domains to no avail and came across KB1012140 ‘Unable to create a trust relationships between Domain Controllers’. The error manifests itself as ‘The local security authority is unable to obtain an RPC connection to the Domain controller.’

Although I was grateful to come across a quick fix for this issue (Just remove the Shared Folders component from VMware Tools which requires a reinstall in 2008 R2), I don’t think the VMware KB article covers the full scope of the issue.

Even if you are not planning on creating any domain trusts, VMware Tools Shared Folders should be removed from all domain controllers.

I kept on getting odd RPC replication errors with Shared folders enabled, even when building new domains to eliminate any other possible causes. Active Directory is the core service of the application layer. Pretty much every other application has a dependency on AD. In an Enterprise environment a low risk approach should always be taken to avoid potential future issues that could result in down time of your core services, especially when the benefit is minimal (i.e. to help lazy support staff). This is especially true if you are virtualising all your domain controllers (a fairly common scenario nowadays) as all your domain controllers will potentially be at risk, guarenteeing a total loss of service.

I have gone a step further and standardised the unattended VMware Tools install for 2008 R2 and removed VMware Tools Shared Folders from all 2008 R2 virtual machines. By extension this needs to include the Thinprint component as well as it seems to have a dependency on Shared Folders. The unattended install is shown here.