Posts Tagged ‘DISA’

Exchange 2010 setup failure in a hardened DISA environment

July 9, 2012 Leave a comment

I had the privilege of setting up a new exchange server on our network and ran into a failure.  During the Hub Transport installation the setup failed because the service wouldn’t start.  Apparently during the Active directory prep, a new group is created called Exchange Servers.  This group is given Manage Auditing and Security permissions on the Domain Controllers.  In our environment we have that setting specified in the Default Domain controllers policy to only allow the Auditors group.  As soon as that policy was refreshed it overwrote what the Exchange setup had done.  It took a while but I finally tracked this down with the help of two other blog postings.


Categories: Computing Tags: , , ,

Remote Share and Storage Management error

July 25, 2011 Leave a comment

On our network we kept running into problems trying to use the remote management tools and we finally found the problem.  The network is locked down pretty hard with DISA security settings and it was one of those settings that caused the problem.  This is seen when you try to use computer management, connect to the server, and try to access the disk management section.  It gives and access denied error.  We just worked around it by using RDP and directly accessing the server.  A couple weeks ago we decided it was time to implement DFS with two file servers for redundancy.  When trying to use the Share and Storage Management RSAT tool we couldn’t connect to the virtual disk service.  Everything I found pointed to the firewall but they were configured properly.  The file servers are running 2008R2 SP1 and the client management workstations are Windows 7 Enterprise with SP1.  We implement all of the DISA security settings via GPO so we were able to create a test OU to play with GPO settings.  It turns out that in a DISA environment, the setting for ‘Access this computer from the network’ was the culprit.  When we added ‘Authenticated User’ everything works again.  It seems that the systems need to be able to ‘talk’ using their computer accounts.  Since these accounts are still authenticated it was no problem getting security to grant an exception.  Hopefully this helps someone else out there.