Azure Active Directory Application Proxy – Part 02

In Part 01 of this series I have explained what is Azure AD application proxy and how it works. If you didn’t read it yet you can find it in http://www.rebeladmin.com/2017/06/azure-active-directory-application-proxy-part-01/

In this part of the series I am going to demonstrate how we can configure Azure AD application proxy.

Demo Setup

In my demo environment I have following,

1. Azure AD Premium Subscription

2. Active Directory 2016 on-premises setup 

3. Web application running on IIS

Enable Azure AD proxy

Before we install application proxy connector, we need to enable application proxy. This only need to enable when setup first application proxy.

1. Log in to Azure as Global Administrator

2. Then open Azure Active Directory 

adapp1

3. In next window click on Application proxy

adapp2

4. In next window click on Enable Application Proxy. Then it will explain about feature and click on Yes to enable. 

adapp3

Install Application Connector

Next step in configuration is to install Application Connector. I am going to install this on same application server.

1. Log in to Azure as Global Administrator

2. Then go to Azure Active Directory | Application Proxy 

3. Then in window click on Download connector 

adapp4

4. It will redirect to a page where you can download the connector. After Accepting terms click Download

adapp5

5. Once file is downloaded, double click on AADApplicationProxyConnectorInstaller.exe to start the connector installation. 

adapp6

6. Then it will open up a wizard. Agree to licenses terms and click on install to proceed. 

adapp7

7. During the installation, it asks for Azure login details. Provide an account which have azure global admin privileges. 

adapp8

8. After login details validates it will continue with the setup. Once it completes we ready to publish the application. 

adapp9

Publish Application

Next stage of the configuration is to publish the application.

1. Log in to Azure as Global Administrator

2. Then go to Azure Active Directory | Enterprise Applications 

adapp10

3. Then in next window, click on New Application 

adapp11

4. In categories page, Click on All and then click on on-premises application 

adapp12

5. Then it’s opens a new window where we can provide configuration data for application.

adapp13

In this form,

Name – Unique name to identify the application

Internal Url – Internal Url for the application. 

External Url – This is auto generated by azure and this url will be the one use to access the application via internet. If need certain url changes can be made. 

All other values we can leave default unless there is specify requirement. 

Once information added, click on Add button to publish the application. 

adapp14

6. Once application is published, we can see it under Enterprises Application

adapp15

Testing

Now we have everything ready. Next step is to verify if its working as expected. by default, application do not have any users assigned. So, before we test, we need to allow application access. 

1. Log in to Azure as Global Administrator

2. Then go to Azure Active Directory | Enterprise Applications | All Applications

3. Click on the web app that we published on previous section. 

4. Then click on Users and Groups

adapp16

5. Then click on Add User in next window

adapp17

6. From the list select the users and click on Select

adapp18

7. Click on Assign to complete the process. 

8. Now under the users you can see the assigned users and groups. 

adapp19

9. Now everything ready! Type the public URL in your browser which is generated during application publish process. For our demo, it was https://webapp1-myrebeladmin.msappproxy.net/webapp1/ . As expected it goes to the Azure login page. 

adapp20

10. Log in using a user account assigned for the app. 

11. After successfully authentication I can see my local web app content! 

adapp21

So as expected, we were able to publish a local application to internet without any DNS, firewall or application configuration change.

Hope this was helpful and if you have any questions feel free to contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Azure Active Directory Application Proxy – Part 01

Today I am going to explain about another great feature which comes with Azure Active Directory. Rebeladmin Corp. does have a CRM application which use by its employees.  This is web based app and hosted in internal network. This app uses windows authentication. From internal, users can log in to it with SSO. Rebeladmin Corp. also uses some application hosted in Azure as well as Office 365. These applications are currently used by its users internal and externally. There was recent requirement that users also want to access this CRM application from external. So, what we can do to allow access from external?

1. Setup VPN, so users can dial in to VPN and access the application through it. 

2. Use ADFS to provide multi factor authentication and SSO from external. ADFS proxy server can place in DMZ to provide more secure connection from external

3. Use Remote Desktop Gateway and Remote Desktop Servers to host application for external access

4. If users are connecting from specific networks, allow direct access to application using edge firewall rules. 

All above solutions can work but it need additional configurations and resource such as,

1. Firewall rules to control traffic between different network segments (DMZ, LAN, WAN) 

2. Public IP addresses and DNS entries for internet facing components

3. Additional servers to host server roles and applications such as ADFS proxy, ADFS Farm, RDG etc. 

4. Additional licenses cost

5. Additional maintenance cost

6. Skills to configure these additional server roles, firewall rules etc. 

Azure Active Directory Application Proxy can integrate on-premises applications with Azure Active Directory and provide secure access with minimum changes to the existing infrastructure. It doesn’t need VPN, additional firewall rules or any other additional servers’ roles. This experience is similar to accessing applications hosted in azure or accessing office 365. This great feature was there for a while but still lots of people do not use this and some not even aware there is such feature available. Whole point of this blog series in to make public aware of this and encourage them to use this.

Why it’s good?

1. This allows organizations to use existing Azure security features to protect the on-premises workloads similar to azure SaaS workloads. 

2. All the components are hosted in cloud so less maintenance. 

3. Simple to setup and no need additional skills to setup different server roles or applications. 

4. If users already familiar with Azure or other Microsoft hosted solutions, the access experience will be similar. Users will not need to train to use different tools to access the hosted applications. (VPN, Remote Desktop etc.)

5. No requirement for public IP address or public DNS entries. It will use public url which is generated during the configuration process and its from Azure. 

However, not every application supported for this method. According to Microsoft it only supports,

Any web application which uses windows authentication or form-based authentication. 

Applications hosted behind RDG (Remote Desktop Gateway)

Web APIs

How it works?

Let’s see how it’s really works in real world.

post-ad app proxy

1. User accessing the published Url for the application from the internet. This URL is similar to application url which is hosted in Azure. This is the azure generate public URL for on premises app. 

2. Then its redirected to log in page and will be authenticate using Azure AD.

3. After successful authentication, it generates a token and send it to user. 

4. Then request is forwarded to Azure AD application proxy. Then it extracts User principle name (UPN) and security principal name (SPN) from the token.

5. Then the request is forwarded to application proxy connector which is hosted in on-premises. This is act as a broker service between application proxy module and web application. 

6. In next step, application proxy connector requests Kerberos ticket which can use to authenticate web application. This request is made on behalf of the user. 

7. On-premise AD issue Kerberos ticket.

8. Kerberos ticket used to authenticate in to web app. 

9. After successful authentication web app send response to application proxy connector. 

10. Application proxy connector send response to the user and he/she can view the web application content. 

Prerequisites

To implement this we need the followings,

Azure AD Basic or Premium Subscription 

Healthy Directory Sync with on-premises AD

Server to install Azure Application Proxy Connector (this can be same server which host web application) 

Supported web application (earlier I mentioned what type of applications are supported)

In next part of this blog series will look in to configuration of Azure AD application proxy. Hope this was helpful and if you have any questions feel free to contact me on rebeladm@live.com   

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

MANAGE AZURE ACTIVE DIRECTORY WITH POWERSHELL – PART 02

In previous part of this blog serious, I have explained how we can install Azure AD PowerShell module and how it can use it to manage Azure Active Directory directly using PowerShell Commands. If you not read it yet you can find it using http://www.rebeladmin.com/2017/02/manage-azure-active-directory-powershell-part-01/

In this post, I am going to explain about another set of cmdlets and the ways to use.

Some of the commands which we use for on-premises Active Directory Management works for Azure Active Directory too. only difference is the cmdlet itself. As an example, in on-premises AD, we use New-ADUser to add user, in Azure AD it becomes New-​Msol​User. If you like to know further about command and its use, easiest way to start is using following commands.

More information about a command can view using,

Get-Help New-​Msol​User -Detailed

Technical Information about thecommand can view using,

Get-Help New-​Msol​User -Full

Online information about the command can view using,

Get-Help New-Msol​User -Online

We also can view some example for the command using,

Get-Help New-Msol​User -Example

power1

We can simply create new user using,

New-MsolUser -UserPrincipalName "jeffm@therebeladmin.com" -DisplayName "Jeff Mak" -FirstName "Jeff" -LastName "Mak" -PasswordNeverExpires $true

power2

In order to create a user, you need to connect to Azure AD with a user who has “Global Admin” role.

In above command UserPrincipalName specify the UPN and user password s set not to expire.

It is obvious sometime we need to change password of an existing account.

Set-MsolUserPassword -UserPrincipalName "jeffm@therebeladmin.com" -NewPassword "pa$$word"

The above command will reset the password for the jeffm@therebeladmin.com in to new password.

Instead of specifying password, following command will generate random password and force user to reset it on next login.

Set-MsolUserPassword -UserPrincipalName "jeffm@therebeladmin.com" -ForceChangePassword $true

power3

Azure Active Directory does have predefined administrative roles with different capabilities. This allows administrators to assign permissions to users to do only certain tasks.

More details about these administrative roles and their capabilities can found on https://docs.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles

We can list down these administrative roles using

Get-MsolRole

power4

According to requirements, we can add users to these administrative roles.

Add-MsolRoleMember -RoleName "User Account Administrator" -RoleMemberObjectId "e74c79ec-250f-4a47-80dd-78022455e383"

Above command will add user with object id e74c79ec-250f-4a47-80dd-78022455e383 to the role.

In order to view existing members of different administrator roles, we can use command similar to below.

$RoleMembers = Get-MsolRole -RoleName "User Account Administrator"

Get-MsolRoleMember -RoleObjectId $RoleMembers.ObjectId

This will list down the users with User Account Administrator role assigned.

power5

Apart from the roles, AD also have security groups.

New-MsolGroup -DisplayName "HelpDesk" -Description "Help Desk Users"

Above command creates a group called HelpDesk

power6

power7

A group contains members. We can add members to group using commands similar to below.

Add-MsolGroupMember -GroupObjectId a53cc08c-6ffa-4bd6-8b03-807740e100f1 -GroupMemberType User -GroupMemberObjectId e74c79ec-250f-4a47-80dd-78022455e383

This will add user with object id e74c79ec-250f-4a47-80dd-78022455e383 to group with object id a53cc08c-6ffa-4bd6-8b03-807740e100f1.

We can list down the users of the group using

Get-MsolGroupMember -GroupObjectId a53cc08c-6ffa-4bd6-8b03-807740e100f1

power8

We can view all the groups and their group ids using

Get-MsolGroup

power9

In order to remove member from the security group we can use Remove-MsoLGroupMember cmdlet.

Remove-MsoLGroupMember -GroupObjectId a53cc08c-6ffa-4bd6-8b03-807740e100f1 -GroupMemberType User -GroupmemberObjectId e74c79ec-250f-4a47-80dd-78022455e383

In order to remove a user from administrator role we can use Remove-MsolRoleMember cmdlet.

Remove-MsolRoleMember -RoleName "User Account Administrator" -RoleMemberType User -RoleMemberObjectId "e74c79ec-250f-4a47-80dd-78022455e383"

Above command will remove user with object id e74c79ec-250f-4a47-80dd-78022455e383 from the group User Account Administrator

This is the end of the part 2 of this series. In next part, we will look further in to Azure AD management with PowerShell.

If you have any questions feel free to contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Microsoft Advanced Threat Analytics (ATA) – Part 02

In previous part of this blog post I have explain what is ATA and what it is capable of. If you not read it yet you can find it in here http://www.rebeladmin.com/2017/05/microsoft-advanced-threat-analytics-ata-part-01/

In this part of the post I am going to demonstrate how we can setup ATA. Before we start I like to explain about the demo environment we going to use.

  • This deployment is going to use AD environment which running AD DS 2016 with Forest and Domain functional levels set to Windows Server 2016.
  •  All the servers used in the demo is running with windows server 2016 with latest updates.
  • The Server which is going to use as ATA center has two IP addresses assigned which is 192.168.0.190 and 192.168.0.191
  • In demo, we are going to use ATA Lightweight Gateway, which will be installed on domain controller directly. There for no port mirroring or separate gateway server required.
  • All the SSL used in deployment are self-signed certificates.
  • We will be using separate service account to connect ATA center with Domain Controller.

First Step of the setup is to get ATA center setup,

Deploying ATA Center

1) Log in to the server which is planned to use as ATA center as domain and or enterprise administrator.

2) Download ATA Center Installation files. It is allowing to use 90 days’ trial as well. 

3) Then run Microsoft ATA Center Setup.exe as Administrator

4) Then In the first window select the relevant language and click Next.

5) In next window, it shows license terms. Read and click on Next to continue

6) Then it asks how you like to know about updates. It is recommended to use Microdot Updates for that. Choose option Use Microsoft Update when I check for updates and then click Next.

7) Then in next window we can define application installation paths, database path, center service IP address and port, SSL certificates, Console IP address. After changes, click on Install to begin the installation. 

ata1

8) Once installation finished, it will give option to launch the ATA center. 

9) After launch ATA center, log in to it using the account used to install ATA center. If you need later you can add additional administrator accounts. 

10) As soon as login, it gives window to provide account and domain info to connect to Active directory. Type the service account info you going to use for this. This account is just a typical user account and no additional permission needed (except read permission for all AD objects). once account details entered, click on test connection option to verify the connection and then click on Save

 ata2

Deploying ATA Lightweight Gateway

1) Log in to the Domain Controller as Domain Admin or Enterprise Admin. 

2) Launch IE and connect to ATA Center URL. It is via the console IP we specify during the ATA center installation. 

3) Log in to ATA center as an Administrator. 

4) In initial page, it will look like following. Click on link Download gateway setup and install the first Gateway

ata3

5) In next page, it gives option to download the Gateway Setup files. Click on the download button to download the installation files. 

ata4

6) After download completes, extract the file and run the Microsoft ATA Gateway Setup.exe 

7) In language page, select the relevant language and click Next to continue.  

8) Then, it will give the confirmation about deployment type. By default, it detects the type as Lightweight Gateway. Click Next to proceed with the deployment.

ata5

9) In next window, we can specify the installation path, SSL certificate information and account details to register the gateway with the ATA center. This account should be a member of ATA administrator group. once all typed in, click on Install to begin the installation. 

ata6

10) Once it completed, log in to ATA center and verify if you can see it is successfully registered. 

ata7

 ATA Testing

 The easiest way to test the ATA functions is to simulate a DNS reconnaissance attack. In order to do that,

1) Log in to a Domain Computer

2) Open the command prompt and type, nslookup – REBE-PDC01.therebeladmin.com and press enter. The server name can be replaced by any available domain controller FQDN. 

3) The type ls msn.com

4) Then log in to ATA center and check the timeline. There we can see the detected event. 

ata8

In here it is only display it as a time line entry, but ATA also allows to send events as email alerts. This configuration can be done using ATA Center > Configuration > Mail Server Settings and Notification Settings

ata9

Then, once an event is raised it will sent out an email alert too.

ata10

This completes the ATA deployment. If you have any questions feel free to contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Microsoft Advanced Threat Analytics (ATA) – Part 01

There are many ways to monitor Active Directory activities in an infastrcure. Some tools are just to monitor the AD services and some tools are to monitor services as well as the activities. Service level monitoring is the easy part and any monitoring tool with windows service monitoring can monitor the status of the AD services. Tools likes SCOM allows to monitor services in more granular level. it is not just monitoring status of the service, it also monitors the AD components and their activities. Windows event log also gives visibility over Active Directory service status and its activities. In a previous blog post I explained how we can enabled advanced active directory auditing which can help to understand what’s going on.

When it comes to security related events, only a tool with auditing capabilities can give some insight. However most of these tools do not give any advice or guidance based on the events it captured. It’s all depend on engineers who analysis those. As an example, an event I sees as a security related event may not see as a threat by a second line support engineer. This is a quite an issues as recent report from Microsoft shows it can take average of 146 days to identify an identity infrastructure security breach. We are fighting against human adversaries, it is obvious we cannot close all the doors. We need to expect a breach. If there is a breach or attempt there should be way to identify it quick as possible and prevent it.

Microsoft is maintaining Active Directory more than 20 years. Microsoft now also have Azure Active Directory. Every day they collect massive amount of security events related to active directory from many different sources. They used these data to build Microsoft Advanced Threat Analytics. It is a simple tool which can identify Active directory infastrcure security threats in early stage and notify engineers about it.

OMS or ATA ?

Microsoft Operation Management Suite also have modules such as AD Assessment, Security and Audit which uses Microsoft Security Graph to identify Active Directory infastrcure threats. OMS not only audit AD activities, it also evaluates existing Active Directory infastrcure setup and provide guidelines to improve it. All these recommends are based on Microsoft security and deployment best practices. OMS also can integrate with Azure Automation to automate operation tasks. It allows engineers to attach a runbook to an alert. In ATA it is only detect and report the problem but it will not take any action about it. I am not saying any of them can replace the other one. Both have different capabilities and its up to you to choose the best one for your environment.

What ATA can detect?

Things that ATA can detect can categorize under 3 areas.

Malicious attacks

  • P ass-the-Ticket (PtT)
  • Pass-the-Hash (PtH)
  • Overpass-the-Hash
  • Forged PAC (MS14-068)
  • Golden Ticket
  • Malicious replications
  • Reconnaissance
  • Brute Force
  • Remote execution
  • Malicious DPAPI

Abnormal behavior

  • Anomalous logins
  • Unknown threats
  • Password sharing
  • Lateral movement

Security issues and risks

  • Broken trust
  • Weak protocols
  • Known protocol
  • Vulnerabilities

ATA Components

ATA Center – ATA center is the operation center. It receives information from ATA gateways and display the detected events in web interface. using ATA center, we also can setup administrators, configure email alerts settings, check the status of connection to gateways. It also can manage the update settings for the gateways.

ATA Gateway – ATA Gateway monitors the traffic which comes to Active Directory Servers. it uses port mirroring technology for it. captured data will passed in to ATA center for evaluation.

ATA Lightweight Gateway – This is the easiest method which can use to install ATA gateway. This component can directly install in Active Directory Domain Controller. However, it will increase the resource usage of the domain controller.

ATA Deployment

There are three ways to deploy ATA,

Using only ATA Gateways – In this deployment mode separate ATA gateways will be used. Domain controllers network ports need to mirror to ATA gateways servers so they can capture the traffic. this is the most reliable method as it will not make any impact on active directory domain controller performance.

Using only ATA Lightweight Gateways – This is most cost effective method of deployment. It will not require separate server and component will be directly install on Domain Controller. It also not required any network layer changes. Only requirement will be to increase the RAM and CPU for the Domain Controller.

Using both ATA Gateways and ATA Lightweight Gateways – In this method, both gateway types will be used. This is ideal deployment mode for branch office environment. In branch office, we can use ATA Lightweight Gateways as it monitor relatively lower traffic.

ata-architecture-topology (1)

Image source : https://docs.microsoft.com/en-gb/advanced-threat-analytics/plan-design/media/ata-architecture-topology.jpg

ATA Prerequisites

  1. ATA center need minimum of Windows server 2012 R2 with latest updates. Recommended at least 4 GB and 2 CPU.
  2. ATA center need to two IP addresses
  3. ATA Lightweight Gateway need minimum of Windows server 2012 R2 with latest updates. Recommended at least 6 GB and 2 CPU.
  4. SSL Certificate for ATA center and gateways. If there is no valid certificate (such as wild card or certificate from internal CA) we can still use self-signed certificate.

Now we have everything ready for the ATA deployment. In next part of this post, I will walk you through the deployment steps.

Hope this was helpful and if you have any question feel free to contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Just Enough Administration (JEA)

I was off from blogging for few months as I had to spend my free time on another task which will help all of you more. Stay tuned! More info will share soon. Anyway, I am back on blogging!

JEA was first introduced in 2014 and it was the first approach towards the privilege access management comes with windows server 2016. JEA allows to provides role based privileges instead of full administrative privileges.

Peter is working in 2nd line support. Every month he needs to run script against helpdesk system to create custom report which indicates monthly support tickets progress. In order to do that he log in to helpdesk server and run the script. This script needs to run as administrator of the server. there for he is member of administrator group. However, this is the only task he run on that server with such privileges. Administrator of a server has privileges to do almost anything on the server. if someone else got access to peter’s account, nothing will prevent from changing entire helpdesk system. Using JEA, we can assign just enough privileges for peter to run the scripts from helpdesk host instead of giving administrator privileges. Privileges assigned for peter is only valid for helpdesk server and he cannot run same script from another server.

There are few limitations with JEA,

  • This is fully worked with PowerShell. Not everyone uses PowerShell.
  •  Not supported with each and every management tasks. If you working with script which works with multiple hosts it will difficult to use JEA.
  • Not every third-party application support to work with JEA.

If above limitations stopping you, most suitable solution with be the privileged access management with windows server 2016. Privileged access management will be covered in later blog post.

There are two components in JEA,

PowerShell Session Configuration file

This allows to map users to the hosts. Using it we can map users, groups to specific management roles. It also allows to configure global settings such as virtual accounts and transcription policies. PowerShell Session Configuration file is system specific. There for, configuration settings can apply per-host basis.

Role Capability files

These configuration files specify what actions can perform by the users. It can be a running a script, running a service, running cmdlets or running a program. These tasks can group in to roles and share it with other users. 

Configuration

In this demo, I am using a system with windows server 2016 with latest updates.

In order to install JEA, we need to log in to the system as local administrator and open the PowerShell.

1. Then run command, Install-Module xJEA. It will ask few questions before it import some modules. Provide appropriate answers to install them.

jea1

2. Once its completed we can confirm it using Find-Module –Name xJEA

jea2

3. Once JEA module installed and next step is to prepare the environment. It can be done using a script which comes with JEA module. it is located at, C:\Program Files\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples\SetupJEA.ps1

This script will,

·         Removes all existing endpoint configuration from the host

·         Configure the DSC Local Configuration Manager to apply changes, then checks every 30 minutes to make sure the configuration has not altered

·         Enables Debug mode

To run the file, navigate to folder C:\Program Files\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples\ and run .\SetupJEA.ps1

jea3

That’s it! we done the installation and initial configuration. 

Testing!

JEA installation comes with 3 demo endpoint configurations which we can use as reference to create endpoint. These demo files are located in C:\Program Files\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples

Demo1.ps1

cls

 

configuration Demo1

{

    Import-DscResource -module xjea

    xJeaToolKit Process

    {

        Name         = 'Process'

        CommandSpecs = @"

Name,Parameter,ValidateSet,ValidatePattern

Get-Process

Get-Service

Stop-Process,Name,calc;notepad

Restart-Service,Name,,^A

"@

    }

    xJeaEndPoint Demo1EP

    {

        Name                   = 'Demo1EP'

        Toolkit                = 'Process'

        SecurityDescriptorSddl = 'O:NSG:BAD:P(A;;GX;;;WD)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)'                                 

        DependsOn              = '[xJeaToolKit]Process'

    }

}

Demo1 -OutputPath C:\JeaDemo

 

Start-DscConfiguration -Path C:\JeaDemo -ComputerName localhost -Verbose -wait -debug -ErrorAction SilentlyContinue -ErrorVariable errors

if($errors | ? FullyQualifiedErrorId -ne 'HRESULT 0x803381fa')

{

    $errors | Write-Error     

}

 

start-sleep -Seconds 30 #Wait for WINRM to restart

 

$s = New-PSSession -cn . -ConfigurationName Demo1EP

Invoke-command $s {get-command} |out-string

Invoke-Command $s {get-command stop-process -Syntax}

# Enter-pssession $s

 

Remove-PSSession $s

#EOF

As per the above it only allowed to use following cmdlets.

  • Default JEA configuration
  • Get-Process
  • Get-Service
  • Stop-Process,Name,calc;notepad
  • Restart-Service,Name

According to above Stop-Process cmdlet only can use to stop calculator and notepad process. But it allows to use Restart-Service, Get-Process, Get-Service cmdlets.

In order to run the demo config, navigate to C:\Program Files\WindowsPowerShell\Modules\xJea\0.2.16.6\Examples and run .\Demo1.ps1

jea4

Once its successfully execute, we can verify the new PowerShell session configuration using,

Get-PSSessionConfiguration

jea5

In order to test, now we need to connect to new endpoint. It can be done using

Enter-PSSession –ComputerName localhost –ConfigurationName demo1ep

In above –ConfigurationName defines the endpoint name.

As soon as I run the command, its connect to the endpoint and change the path to C:\Users\JSA-Demo1EP\Documents

jea6

in the backend JEA commands execute using JEA local administrator account. This login details no need to know by end users and its password been reset on daily basis automatically. This user is setup as part of the installation process by JEA.

jea7

jea8

Once session is connected, we can test it with an allowed command first. According to configuration we allowed to run Get-Service command without any limits.

jea9

The use I logged in to this computer is a local administrator. So, I have enough privileges to restart the computer using Restart-Computer cmdlet. But now I am connected to endpoint. According to endpoint config it should not allow me to do so.

jea10

Voila! It is working as expected. there are lot of channel9 videos, articles out there which discuss about JEA capabilities. I encourage you to go through them and get more understanding on this great tool. Also through the GitHub you can find lot of sample endpoint configurations.

Hope this post was helpful and if you have any question contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Manage Azure Active Directory with PowerShell – Part 01

In this series of articles, it which will explain how to use PowerShell to manage your Azure Active Directory instance. In Part 01, I am going to show how to connect with Azure AD using PowerShell and show actions of some day to day operation related commands.

In order to use PowerShell with Azure AD, first we need to install Azure Active Directory Module in local computer. there is two version of Azure active directory PowerShell module. One was made for the Public Preview and the latest one released after announces Azure AD GA. You can download module from http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

If you had the previous version installed, highly recommended to replace it with the new version.

Once installed let’s check its status.

Get-Module MSOnline

mson1

In order to list down all the commands associate cmdlets with the module we can use

Get-Command -Module MSOnline

mson2

Next step is to connect to Azure AD Instance. In order to do that we can use,

Connect-MsolService

It will prompt for the login details. Please use your Azure DC Admin account details. Please note login via Microsoft account not supported.

First, we can list down all the domain under the given subscription. To do that we can use,

Get-MsolDomain

mson3

As next steps I like to list down all the users in Azure AD Setup.

Get-MsolUser

mson4

It will list down all the Users in the Azure AD.

I also can search for a specific user based on text patterns. In below example I am searching users with Name which match text “Dishan”

Get-MsolUser -SearchString "Dishan"

Idea of my search is to find some object values for this user. I can combine above command to return all the object value.

Get-MsolUser -SearchString "Dishan" | Select-Object *

mson5

Now we know what are the objects been use and I can make more unique search.

Get-MsolUser | Select-Object DisplayName,whenCreated,LastPasswordChangeTimestamp

Above command will list me all the users with Display Name, Date and Time It was created, and Date and Time of Last Password Change Action.

mson6

Get-MsolUserRole another handy cmdlet. It can use to check the role of a user account.

Get-MsolUserRole -UserPrincipalName "dcadmin@REBELADMIN.onmicrosoft.com" | fl

The above command will find the role for the given user account.

mson7

Get-MsolGroup cmdlet can use to list, filter Groups in the Azure AD.

mson8

Using searchstring can search for the groups based on text patterns.

Get-MsolGroup -SearchString "AAD"

mson9

Get-MsolGroupMember can use to list down the members in the group.

Get-MsolGroupMember -GroupObjectId "77a76005-02df-48d5-af63-91a19ed55a82"

mson10

Remove-MsolUser cmdlet can use to remove the user object from the Azure AD. This can combine with searchstring to search for user and then remove the object same time.

Get-MsolUser -SearchString "user2" | Remove-MsolUser

Above command will search for the user object which have display name similar to user2 and then delete it.

mson11

In next post let’s dig further in to cmdlets which can use to manage Azure AD.

If there is any question, please feel free to contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Time Based Group Membership – AD DS 2016

In new AD DS 2016 allows administrators to assign temporally group membership which is expressed by TTL (Time-To-Live) value. This value will add to the Kerberos ticket. This also called as “Expiring-Link” feature. When user assign to a temporally group membership, his login Kerberos ticket granting ticket (TGT) life time will be equal to lowest TTL value he has. 

This feature is not enabled by default. The reason for that is, to use this feature the forest function level must be windows server 2016. Also, once this feature is enabled, it cannot be disabled. 

Let’s see how it works

Enable-ADOptionalFeature ‘Privileged Access Management Feature’ -Scope ForestOrConfigurationSet -Target rebeladmin.com

tg2

Rebeladmin.com can be replaced with your FQDN.

I have a user called Peter which I need to assign Domain Admin group membership for 15 minutes.

Get-ADGroupMember “Domain Admins” will list the current member of domain admin group. 

tg1

Next step is to add the peter to the domain admin group for 15 minutes.

Add-ADGroupMember -Identity ‘Domain Admins’ -Members ‘peter’ -MemberTimeToLive (New-TimeSpan -Minutes 15)

tg3

Once its run, we can verify the TTL value remaining for the group membership using,

Get-ADGroup ‘Domain Admins’ -Property member -ShowMemberTimeToLive

tg4

Once I log in as the user and list the Kerberos ticket it shows the renew time with less than 15 minutes as I log in as user after few minutes of granting.

tg5

Once the TGT renewal come the user will no longer be member of domain admin group. 

hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com

Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Step-by-Step guide to configure site-to-site VPN Gateway connection between Azure and on-premises network

When you are in hybrid cloud setup with azure, using site-to-site VPN gateway you can have better continuity for your workloads. in this post, I am going to demonstrate how to set up site-to-site VPN Gateway.

Requirements 

Before start make sure you have following in place. 

1) VPN device – you need to have VPN device in on-premises to create the VPN connection with azure. the supported list of devices can found on here. Also, you need to have the relevant knowledge to configure it on your device. I am not going to cover it in details here as settings are different based on the vendor. 

2) Static Public IP address – your VPN device should have external public IP address and it shouldn’t be NAT. 

3) Valid Azure Subscription – Of because you need active Azure subscription. It can be paid or free trial. 

Create Virtual Network 
 
If you already have virtual network setup in your azure subscription, you will not need to do this step but make sure the settings are correct. 
 
1) Log in to the azure portal.
2) Go to New > Networking > Virtual Network 
vpn1
 
3) Then click on create 
vpn2
 
4) In next page, it will open up the wizard with the VNet information. In their fill the information to match with your configuration.
vpn3
 
Name – Name for the VNet
Address Space – IP range for the VNet. If you have multiple Address ranges, it can add later. 
Subnet name – Name for the subnet you like to add 
Subnet Address range – Subnet IP range (it must be within the Address Space listed before)
Resource Group – Can create new group or select existing group
Location – location of the VNet
 
After that click on create continue.
5) Once VNet created, can modify the address ranges and subnets.
vpn4
 
Create Gateway Subnet 
 
Next step is to create gateway subnet for the VNet. It is recommended to use /28 or /27 for gateway subnet. This need to be done before connecting VNet to the gateway. 
 
1) Log in to the Azure Portal
2) Then go to More Services > Virtual Networks 
vpn5
 
3) Then click on the VNet, created on previous step and click on subnets. Then click on gateway subnet 
vpn6
 
4) In the next window define the subnet for the gateway and click OK
vpn7
vpn8
Create Virtual Network Gateway
 
Next step is to create virtual network gateway. 
 
1) Log in to azure portal 
2) Go to New > Networking > Virtual Network Gateway 
vpn9
 
3) In next window fill the relevant information and click on Create
vpn10
 
Name – Name for the virtual network gateway
Gateway Type – For our VPN it will be VPN 
VPN Type – Type of the VPN and regular VPN will be route-based
SKU – SKU for the VPN type
Virtual Network – in here select the VNet you have created following previous step
Public IP Address – VPN need to have public IP address. Select public IP from here or if you don’t have, once you click on the option it will allow you to add new one. 
Location – make sure you select the correct region to match with VNet region. 
 
4) It can take up to 45 minutes to complete the task. Once it’s done can see the public IP address details. You need this to configure the VPN device in yours on premises device. 
vpn11
 
Create Local Network Gateway
 
The next step is to create local gateway which represent your local network. To create it,
 
1) Log in to azure portal
2) Go to New > Networking > Local network gateway
vpn12
 
3) Then it will open new wizard and fill the relevant information. After that click on create to proceed
vpn13

Name – Name for the local gateway 
IP Address – Public IP address to represent your VPN device. It should not behind NAT. 
Address Space – This is yours on premises address ranges. You can add multiple ranges.
Resource Group – you can create new resource group or use the same one you were using. 
vpn14
 
Create Site-to-Site VPN
 
Then next step is to create Site-to-Site VPN connection between your VPN device and the virtual network gateway. To create it,
 
1) Log in to azure portal
2) Go to More Services > Virtual network gateways 
vpn15
 
3) Then click on the virtual network gateway you created and, under the settings tab, click on connection
vpn16
 
4) Then click on add
vpn17
 
5) In the wizard fill the relevant information and click ok
vpn18

Name – Name of the connection 
Connection Type – Type of the VPN. Most of the time its site-to-site
Virtual Network Gateway – you need to select the relevant virtual network gateway
Local Network Gateway – in here need to select the relevant local network gateway for your connection
Shared Key – This is the pre-shared key you going to use for the VPN configuration
 
6) Once its created it’s all about configuring the VPN in your VPN device. 
7) Once connected you can see the status in same page by clicking on connection
vpn19

 
 
Hope this was helpful and if you have any questions feel free to contact me on rebeladm@live.com
Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter

Step-by-Step guide to migrate active directory FSMO roles from windows server 2012 R2 to windows server 2016

Windows server 2016 was released for public (GA) on mid oct 2016. Its exciting time as businesses are already working on migrating their services in to new windows server 2016 infrastructures. In this post, I am going to explain how you can migrate from active directory running on windows server 2012 R2 to windows server 2016 active directory. The same steps are valid for migrating from windows server 2012, windows server 2008 R2 and windows server 2008.

In my demo setup, I have a windows server 2012 R2 domain controller as PDC. I setup windows server 2016 and already added to the existing domain.

updc1

Current domain and forest functional level of the domain is windows server 2012 R2.

updc2

So, let’s start with the migrate process. 

Install Active Directory on windows server 2016
 
1. Log in to windows server 2016 as domain administrator or enterprise administrator
2. Check the IP address details and put the local host IP address as the primary DNS and another AD server as secondary DNS. This is because after AD install, server itself will act as DNS server
3. Run servermanager.exe form PowerShell to open server manager (there is many ways to open it) 
updc3
 
4. Then click on Add Roles and Features
updc4
 
5. It will open up the wizard, click next to continue
updc5
 
6. In next window keep the default and click next
updc6
 
7. Roles will be installed on same server, so leave the default selection and click next to continue
updc7
 
8. Under the server roles tick on Active Directory Domain Services, then it will prompt with the features needs for the role. Click on add features. Then click next to proceed
updc8
updc9
updc10
 
9. On the features windows keep the default and click next
updc11
 
10. In next window, it will give brief description about AD DS, click next to proceed 
updc12
 
11. Then in next window it will give brief description about configuration and click on install to start the role installation process. 
updc13
updc14
 
12. Once installation completed, click on promote this server to a domain controller option
updc15
 
13. It will open up the Active Directory Domain Service configuration wizard, leave the option Add a domain controller to existing domain selected and click next.
updc16
 
14. In next window define a DSRM password and click next
updc17
 
15. In next window click on next to proceed
updc18
 
16. In next windows, it asks from where to replicate domain information. You can select the specific server or leave it default. Once done click next to proceed. 
updc19
 
17. Then it shows the paths for AD DS database, log files and SYSVOL folder. You can change the paths or leave default. In demo, I will keep default and click next to continue
updc20
 
18. In next windows, it will explain about preparation options. Since this is first windows server 2016 AD on the domain it will run forest and domain preparation task as part of the configuration process. Click next to proceed.
updc21
 
19. In next window, it will list down the options we selected. Click next to proceed. 
updc22
 
20. Then it will run prerequisite check, if all good click on install to start the configuration process.
updc23
 
21. Once the installation completes it will restart the server. 
updc24
 
Migrate FSMO Roles to windows server 2016 AD
 
I assume by now you have idea what is FSMO roles. If not search my blog and you will find article explaining those roles. 
There are 2 ways to move the FSMO roles from one AD server to another. One is using GUI and other one is using command line. I had already written articles about GUI method before so I am going to use PowerShell this time to move FSMO roles. If you like to use GUI mode search my blog and you will find articles on it. 
 
1) Log in to windows server 2016 AD as enterprise administrator
2) Open up the Powershell as administrator. Then type netdom query fsmo. This will list down the FSMO roles and its current owner. 
updc25
 
3) In my demo, the windows server 2012 R2 DC server holds all 5 fsmo roles. Now to move fsmo roles over, type Move-ADDirectoryServerOperationMasterRole -Identity REBELTEST-PDC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster and press enter
 
In here REBELTEST-PDC01 is the windows server 2016 DC. If FSMO roles are placed on different servers, you can migrate each and every FSMO roles to different servers. 
updc26
 
4) Once its completed, type netdom query fsmo again and you can see now its windows server 2016 DC is the new FSMO roles owner. 
updc27

 
Uninstall AD role from windows server 2012 R2
 
Now we moved FSMO roles but we still running system on windows 2012 R2 domain and forest functional levels. In order to upgrade it, first we need to decommission AD roles from existing windows server 2012 R2 servers. 
 
1) Log in to windows 2012 R2 domain server as enterprise administrator
2) Open the PowerShell as administrator
3) Then type Uninstall-ADDSDomainController -DemoteOperationMasterRole -RemoveApplicationPartition and press enter. It will ask for local administrator password. provide new password for local administrator and press enter.
updc28
updc29
updc30
 
4) Once its completed it will restart the server.
 
Upgrade the forest and domain functional levels to windows server 2016
 
Now we have the windows server 2012 R2 domain controllers demoted, next step is to upgrade domain and forest functional levels. 
 
1) Log in to windows server 2016 DC as enterprise administrator 
2) Open PowerShell as administrator
3) Then type Set-ADDomainMode –identity rebeladmin.net -DomainMode Windows2016Domain to upgrade domain functional level to windows server 2016.  In here rebeladmin.net is the domain name. 
updc31
 
4) Then type Set-ADForestMode -Identity rebeladmin.net -ForestMode Windows2016Forest to upgrade forest functional level.
updc32
 
5) Once done you can run Get-ADDomain | fl Name,DomainMode and Get-ADForest | fl Name,ForestMode to confirm new domain and functional level 
updc33
 
Hope this post was useful and if you got any questions feel free to contact me on rebeladm@live.com


Share and Enjoy:
  • Print
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Live
  • RSS
  • StumbleUpon
  • Twitter