70-742 Additional Notes – Federation Services Cmdlets for PowerShell

September 16, 2017 at 11:50 am

Be sure to run through these useful cmdlets for the management of Active Directory Federation Services. Remember, don’t go crazy with memorization here on cmdlets. Just remember the verb-noun syntax and review the list to see what is possible. Once again – don’t miss the READ MORE button in the blog post to see the complete list:

  • Add-​Adfs​Attribute​Store
    Adds an attribute store to the Federation Service.
  • Add-​Adfs​Certificate
    Adds a new certificate to AD FS for signing, decrypting, or securing communications.
  • Add-​Adfs​Claim​Description
    Adds a claim description to the Federation Service.
  • Add-​Adfs​Claims​Provider​Trust
    Adds a new claims provider trust to the Federation Service.
  • Add-​Adfs​Claims​Provider​Trusts​Group
    Creates a claims provider trust group based on metadata that contains multiple entities.
  • Add-​Adfs​Client
    Registers an OAuth 2.0 client with AD FS.
  • Add-​Adfs​Device​Registration​Upn​Suffix
    Adds a custom UPN suffix.
  • Add-​Adfs​Farm​Node
    Adds this computer to an existing federation server farm.
  • Add-​Adfs​Local​Claims​Provider​Trust
    Creates a local claims provider trust.
  • Add-​Adfs​Native​Client​Application
    Adds a native client application role to an application in AD FS.
  • Add-​Adfs​Non​Claims​Aware​Relying​Party​Trust
    Adds a relying party trust that represents a non-claims-aware web application or service to the Federation Service.
  • Add-​Adfs​Relying​Party​Trust
    Adds a new relying party trust to the Federation Service.
  • Add-​Adfs​Relying​Party​Trusts​Group
    Creates a relying party trusts group.
  • Add-​Adfs​Scope​Description
    Adds a scope description in AD FS.
  • Add-​Adfs​Server​Application
    Adds a server application role to an application in AD FS.
  • Add-​Adfs​Trusted​Federation​Partner
    Adds configuration settings for trusted federation partners in AD FS.
  • Add-​Adfs​Web​Api​Application
    Adds a Web API application role to an application in AD FS.
  • Add-​Adfs​Web​Application​Proxy​Relying​Party​Trust
    Adds a relying party trust for the Web Application Proxy.
  • Disable-​Adfs​Application​Group
    Disables an application group.

70-742 Additional Notes – Active Directory Rights Management Services (AD RMS)

September 14, 2017 at 9:32 pm

Active Directory Rights Management Services rights can be assigned to users in forests that have a federated trust in place via Active Directory Federation Services . This enables organizations to share rights-protected content without establishing another trust or building a separate Active Directory Rights Management Services infrastructure.

Active Directory Federation Services (AD FS) is a standards-based service that enables federation of identity by implementing claims-based authentication across forests. Claims-based authentication is the process of authenticating a user, based on a set of claims contained in a trusted token. The token is typically issued and signed by a trusted entity.

With AD FS, identity federation is established between two organizations by establishing trust between two security realms . An AD FS server on one side of the trust (ADFS-ACCOUNT) authenticates the user through Active Directory Domain Services and issues a token containing a series of claims about the user, including her identity. On the other side, an AD FS server (ADFS-RESOURCE) validates the token and issues a separate token that the local servers accept, enabling the user to access a requested resource. This process enables an organization to provide controlled access, to its resources or services, to a user that belongs to another security realm. Users do not have to directly authenticate to the federated environment and the organizations do not have to share user identities or passwords.

In order to benefit from identity federation, a service must accept federated identities, and AD RMS is one such service. In particular, AD RMS is designed to accept requests for licenses, from remote users through a single sign-on agent or Web single sign-on, and redirect the requests to the local federation server (ADFS-RESOURCE). This server requires the user to authenticate to ADFS-ACCOUNT, which authenticates the user via Active Directory and issues the corresponding security token. This token is presented to the single sign-on agent, which validates the token and provides the identity to the AD RMS server. Finally, the AD RMS server issues the requested licenses.

AD FS provides a very efficient way to deliver access to protected content to users in remote, independent organizations, including organizations that have not deployed AD RMS. It also uses infrastructure that can be used for other federation purposes, such as providing access to extranet sites and to SharePoint Server based sites.

Trusted User Domains (TUDs) allow you to configure an AD RMS cluster to manage requests for CLCs for users that have been issued RACs from a different AD RMS cluster. For example, if an organization has two separate Active Directory forests and each forest has its own AD RMS deployment, you’d configure Trusted User Domains so that clients from one forest are able to issue CLCs to clients with RACs issued from the other forest. TUDs can be one-way or bi-directional. When configuring TUDs, you must export the TUD from the partner before importing the TUD locally.

Trusted Publishing Domains (TPDs) allow the AD RMS cluster in one forest to issue end-user licenses to content published with licenses issued from an AD RMS cluster in another forest. You must export the TPD file and have it imported by the partner AD RMS cluster before the AD RMS cluster in the partner forest can issue end-user licenses to local AD RMS clients.

70-742 Additional Notes – Default Windows Server Security Groups

September 13, 2017 at 10:02 pm

GPOs

It is super important to be familiar with the default security groups of Active Directory and their purpose. Here is a handy review for you! While most I am sure you are familiar with – some might be a surprise a perhaps you have never needed them in your Enterprise. The exam of course does not care! Be sure to locate the READ MORE link as this list DOES NOT end after Domain Users. 🙂

  • Access Control Assistance Operators – Members of this group can remotely query authorization attributes and permissions for resources on the computer.
  • Account Operators – The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including those of users, local groups, and global groups, and members can log in locally to domain controllers.
  • Administrators – Members of the Administrators group have complete and unrestricted access to the computer, or if the computer is promoted to a domain controller, members have unrestricted access to the domain.
  • Allowed RODC Password Replication Group – The purpose of this security group is to manage a RODC password replication policy. This group has no members by default, and it results in the condition that new Read-only domain controllers do not cache user credentials. The Denied RODC Password Replication Group group contains a variety of high-privilege accounts and security groups. The Denied RODC Password Replication group supersedes the Allowed RODC Password Replication group.
  • Backup Operators – Members of the Backup Operators group can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to and shut down the computer. This group cannot be renamed, deleted, or moved. By default, this built-in group has no members, and it can perform backup and restore operations on domain controllers. Its membership can be modified by the following groups: default service Administrators, Domain Admins in the domain, or Enterprise Admins. It cannot modify the membership of any administrative groups. While members of this group cannot change server settings or modify the configuration of the directory, they do have the permissions needed to replace files (including operating system files) on domain controllers. Because of this, members of this group are considered service administrators.
  • Certificate Service DCOM Access – Members of this group are allowed to connect to certification authorities in the enterprise.
  • Cert Publishers – Members of the Cert Publishers group are authorized to publish certificates for User objects in Active Directory.
  • Cloneable Domain Controllers – Members of the Cloneable Domain Controllers group that are domain controllers may be cloned. In Windows Server 2012 R2 and Windows Server 2012, you can deploy domain controllers by copying an existing virtual domain controller. In a virtual environment, you no longer have to repeatedly deploy a server image that is prepared by using sysprep.exe, promote the server to a domain controller, and then complete additional configuration requirements for deploying each domain controller (including adding the virtual domain controller to this security group).
  • Cryptographic Operators – Members of this group are authorized to perform cryptographic operations. This security group was added in Windows Vista Service Pack 1 (SP1) to configure Windows Firewall for IPsec in Common Criteria mode.
  • Denied RODC Password Replication Group – Members of the Denied RODC Password Replication group cannot have their passwords replicated to any Read-only domain controller.
  • Distributed COM Users – Members of the Distributed COM Users group are allowed to launch, activate, and use Distributed COM objects on the computer. Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. Distributed Component Object Model (DCOM) allows applications to be distributed across locations that make the most sense to you and to the application. This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
  • DnsUpdateProxy – Members of the DnsUpdateProxy group are DNS clients. They are permitted to perform dynamic updates on behalf of other clients (such as DHCP servers). A DNS server can develop stale resource records when a DHCP server is configured to dynamically register host (A) and pointer (PTR) resource records on behalf of DHCP clients by using dynamic update. Adding clients to this security group mitigates this scenario.However, to protect against unsecured records or to permit members of the DnsUpdateProxy group to register records in zones that allow only secured dynamic updates, you must create a dedicated user account and configure DHCP servers to perform DNS dynamic updates by using the credentials of this account (user name, password, and domain). Multiple DHCP servers can use the credentials of one dedicated user account.
  • DnsAdmins – Members of DNSAdmins group have access to network DNS information. The default permissions are as follows: Allow: Read, Write, Create All Child objects, Delete Child objects, Special Permissions.
  • Domain Admins – Members of the Domain Admins security group are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. The Domain Admins group is the default owner of any object that is created in Active Directory for the domain by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group. The Domain Admins group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain. Membership can be modified by members of the service administrator groups in its domain (Administrators and Domain Admins), and by members of the Enterprise Admins group. This is considered a service administrator account because its members have full access to the domain controllers in a domain.
  • Domain Computers – This group can include all computers and servers that have joined the domain, excluding domain controllers. By default, any computer account that is created automatically becomes a member of this group.
  • Domain Controllers – The Domain Controllers group can include all domain controllers in the domain. New domain controllers are automatically added to this group.
  • Domain Guests – The Domain Guests group includes the domain’s built-in Guest account. When members of this group sign in as local guests on a domain-joined computer, a domain profile is created on the local computer.
  • Domain Users – The Domain Users group includes all user accounts in a domain. When you create a user account in a domain, it is automatically added to this group. By default, any user account that is created in the domain automatically becomes a member of this group. This group can be used to represent all users in the domain. For example, if you want all domain users to have access to a printer, you can assign permissions for the printer to this group (or add the Domain Users group to a local group on the print server that has permissions for the printer).

70-742 Additional Notes – Item-Level Targeting with Group Policy Objects (GPO)

September 1, 2017 at 4:13 pm

GPO

Item-level targeting is a feature of Group Policy that allows preference settings to be applied to individual users and/or computers within the scope of the Group Policy Object (GPO) that contains the preferences. Policy settings can also be filtered, but there are several important differences between item-level targeting of preference settings and the filters that can be used with policy settings:

  • Policy settings within a GPO can only be filtered on an all-or-nothing basis: either the entire GPO will apply to a target or it won’t. Item-level targeting allows individual preference settings within a GPO to be applied or not, based on specified criteria. Different preference settings can be applied to different groups of targets.
  • Policy settings are filtered using either security filters or WMI filters. Security filters are static and not very granular. WMI filters are dynamic and can be very granular, but the WMI Query Language in which they are written is complex and has a steep learning curve. Item-level targeting provides a great deal of granularity and an intuitive user interface for constructing filters.
  • Item-level targeting allows an administrator to specify a list of conditions that must be met in order for a preference setting to be applied to a user or computer object. The conditions in the list are connected by Boolean AND or OR operators. When the list is evaluated, if the result is true, the setting is applied; if the result is false, it isn’t.

A wide variety of criteria are available for targeting settings to users and computers, including the following:

  • Battery Present Targeting
  • Computer Name Targeting
  • CPU Speed Targeting
  • Date Match Targeting
  • Disk Space Targeting
  • Domain Targeting
  • Environment Variable Targeting
  • File Match Targeting
  • IP Address Range Targeting
  • Language Targeting
  • LDAP Query Targeting
  • MAC Address Range Targeting
  • MSI Query Targeting
  • Network Connection Targeting
  • Operating System Targeting
  • Organizational Unit Targeting
  • PCMCIA Present Targeting
  • Portable Computer Targeting
  • Processing Mode Targeting
  • RAM Targeting
  • Registry Match Targeting
  • Security Group Targeting
  • Site Targeting
  • Terminal Session Targeting
  • Time Range Targeting
  • User Targeting
  • WMI Query Targeting

70-742 Additional Notes – Software Deployment Using Group Policy

August 23, 2017 at 7:25 pm

70-742

Group Policy is one of your many options for automating the deployment of software in your Enterprise and is a huge topic for the 70-742 exam. You can use such policy to deploy applications to computer or users. Be sure to audit your Group Policy settings to ensure that you are only deploying the application once to a target user or system. Obviously, whenever possible, consider having the policy for distribution as high up in the directory structure as possible.

Windows Installer packages make software distribution in in this manner possible. You assign or publish the software using Software Installation in Group Policy. This is only possible if your file type fits one of the following categories:

  • Native Windows Installer package (.msi)
    • Provide the best overall deployment experience
    • Take full advantage of the Windows Installer
    • Allows for components to install on demand and also permits applications to self heal
    • You can enact modifications with a .mst file
    • You can enact software patches with a .msp file
  • Repackaged application (.msi) files
    • You can repackage an application that does not have a native Windows Installer Package
    • Keep in mind that the installation occurs as a single component; unlike what is possible with native Windows Installer Packages
  • An application file (.zap) – this installs the application by using its original setup.exe program; note that these files can only be published, not assigned
    • Define the setup.exe or install.exe into a .zap file in order to deploy them
    • A .zap file is a text file that contains information on how to publish the application
    • This approach is less flexible than native Windows Installer packages – for example, you would not be able to override the need for administrative privileges for installation

    InformIT (Pearson Education)

70-742 Additional Notes – Standalone Certificate Authorities

August 20, 2017 at 1:54 pm

70-742

Overview

Stand-alone certification authorities (CAs) can issue certificates for purposes such as:

  • Digital signatures
  • Secure e-mail by using S/MIME (Secure Multipurpose Internet Mail Extensions)
  • Authentication to a secure Web server by using Secure Sockets Layer (SSL) or Transport Layer Security (TLS)

Characteristics

  • Unlike an enterprise CA, a stand-alone CA does not require the use of Active Directory Domain Services (AD DS). Even if you are using AD DS, stand-alone CAs can be used as offline trusted root CAs in a CA hierarchy or to issue certificates to clients over an extranet or the Internet.
  • When users submit a certificate request to a stand-alone CA, they must provide their identifying information and specify the type of certificate they need. (This does not need to be done when submitting a request to an enterprise CA because the enterprise user’s information is already in AD DS and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer’s Security Accounts Manager database.
  • By default, all certificate requests sent to the stand-alone CA are set to pending until the administrator of the stand-alone CA verifies the submitted information and approves the request. The administrator has to perform these tasks because the certificate requester’s credentials are not verified by the stand-alone CA.
  • Certificate templates are not used.
  • The administrator has to explicitly distribute the stand-alone CA’s certificate to the domain user’s trusted root store, or users must perform that task themselves.
  • If a cryptographic provider supporting elliptic curve cryptography (ECC) is used, a stand-alone CA will honor every key usage for the ECC key.

When a stand-alone CA uses AD DS, the CA has these additional features:

  • If a member of the Domain Admins group or an administrator with Write access to a domain controller installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.
  • If a stand-alone CA is installed by a member of the Domain Admins group of the parent domain in the enterprise, or by an administrator with Write access to AD DS, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to AD DS.