ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Manage Local Computer Administrators with GPO restricted groups

Summary:  

Create separate user account or security group to manage domain computers.  This account cannot have domain admin privileges.


Problem:  

System Administrators log onto workstations and general purpose servers with their domain admin account.  Casual use of domain administrator accounts put the entire organization at risk of compromise from malware, keyloggers, and hash attacks.

Goal:  

Primary goal prevents network administrators from using domain admin accounts for purposes other than Active Directory tasks.  Secondary goal provides a general purpose administrative access for support staff and management.   

Solution:  

Implement GPO restricted groups provide administrator (i.e., non-domain admin) to manage computers. Steps:

  1. Create new security group in AD.  This group will be used to manage computers.  Add domain users to this group as needed.
     
  2. Create Restricted Group GPO.

    Computer Configuration\Policies \Windows Settings\Security Settings\Restricted Groups\

  3. Right click on Restricted Groups.  Left click on Add Group. 
  • Members of this group (i.e., domain group):  New AD security group created in Step 1.
  •  The Group is a member of (i.e., local group):  This is the local security group for each workstation (e.g., Administrators).
      4.  Assign new GPO to AD OU.  Wait for change to propagate.
  No more unnecessary use of domain admin accounts.  That's It!

References: 

https://support.microsoft.com/en-us/kb/279301
http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx


How to Fix Primary Domain Trust Failures

Error:  

The trust relationship between this workstation and the primary domain failed.

Problem:  

Domain computers use internal passwords to authenticate with Active Directory (AD).  Servers and workstations automatically reset their passwords every 30 days.  Suspended virtual machines or server backups may not logon domain users if the computer has a new password in AD.

Solution:   

Fix domain trust issues: (1) in AD, and (2) on the computer.

  1.    Reset the computer account in Active Directory Users and Computers (ADUC). 

    Open ADUC → Computers OU → Right-Click on the computer → Reset Accout

  2.  Reset the computer with PowerShell.  N.B., This step requires local Administrative rights.  We can't reset the computer, or even re-join the domain, with out the ability to log on locally.

    From PowerShell:  Reset-ComputerMachinePassword 
That's It!

References:  http://technet.microsoft.com/en-us/library/hh849751.aspx

Back up Windows 2012 Active Directory (AD) with DPM 2010


Last updated  October 13th, 2013 by Steven Jordan


Backup 2012 AD with 2010 DPM.

Disclaimer:  Microsoft does not support DPM 2010 backup for Windows 2012 servers.  I have found however, the backup process still works.  I have only run into 2 (resolvable) issues so far:
  1. Automatic installation of the DPM 2010 installation agent on Windows 2012 servers no longer works.  The DPM agent must be installed manually.  See my previous post on DPM for instructions.
  2. DPM 2010 backups of the system state for Windows 2012 server with Active Directory (AD) server installed failed. 

    Windows Server Backup must be installed on the Windows 2010 AD server in order to backup the system state.  This is only true for 2012 servers with AD roles installed.  After the Windows Server Backup feature was installed there were no longer problems with related DPM backups. 

Enable Windows Remote Assistance

Problem:   

 IT support staff require an easy method to support remote staff.  Microsoft Lync provides remote desktop viewing but it does not provide Administrative assistance.  Third-party solutions exist but require subscriptions, etc. 

Solution:

 Enable Windows Remote Assistance (RA).  Windows Remote Assistance has improved from the Vista days when it was first released.  When properly enabled, IT staff can initiate an unsolicited RA session to any workstation on the domain; the entire process is simple and intuitive.

Enable RA:

   First, create a "Remote Assistance" GPO within Group Policy Management. Within the GPO there should be 2 policies enabled:
    First GPO:
Computer Configuration\Administrative Templates\Network\Network Connections\Windows Firewall\Domain Profile\Windows Firewall\Define inbound program exceptions:  enabled.
    Add Exceptions to GPO Attribute:
%WINDIR%\SYSTEM32\Sessmgr.exe:*:Enabled:Remote Assistance
%WINDIR%\PCHealth\HelpCtr\Binaries\Helpsvc.exe:*:Enabled:Offer Remote Assistance
%WINDIR%\PCHealth\HelpCtr\Binaries\Helpctr.exe:*:Enabled:Remote Assistance – Windows Messenger and Voice
   Second GPO:
Computer Configuration\Administrative Templates\System\Remote Assistance\Configure Offer Remote Assistance:  enabled.
    Create RA Security Group:
  • Specify AD security group or users to permit remote control of domain workstations.
  • Assign the RA GPO to workstations OU.

  • Once the RA policy has propagated the workstations are ready for administrative remote assistance.

    Managing RA: 

       Providing remote desktop support is a simple process.  IT staff can run the following command to start the remote session:
    Msra.exe /offerRA computer-name
       The Msra command works with both hostname (i.e. computer name) or IP address.  Msra starts the remote session with an end-user request.  The end-user receives a pop-up window that requests permission to start the RA session.

    That's It!

    References:

    http://technet.microsoft.com/en-us/magazine/ff356868.aspx




    The last token starts with 'd'


    Problem:   I recently demoted a Certificate Authority server from Windows 2008.  While deleting the remaining CA objects from Active Directory per:  

         ldifde -i -f remainingCAobjects.ldf

         I received the following error:  

    There is a syntax error in the input file failed on line 3.  The last token starts with 'd'  0 entries modified successfully.  An error occurred in the program.

    Resolution:  Edit the the ldf file so that there is not any data/ text below the "changetype:  delete" line.  If we were adding or modifying AD entries additional directives are expected.  When deleting AD entries the LDIF file only needs the DN and the "changetype=delete" directive.  Working example:   

         dn: cn=Bill Gates,ou=people,dc=microsoft,dc=com  

         changetype: delete

    P.S.  This post has been surprisingly popular.   Please leave comments.  Thanks!  -SMJ


    References:
    http://docs.oracle.com/cd/B14099_19/idmanage.1012/b15883/ldif_appendix002.htm#CHDFECDI
    http://support.microsoft.com/kb/889250