Are You Winning? Finding the Middle Ground for a Healthy Work–Life Balance in IT Consulting

Posted on by Alan Schmarr

If you’ve spent any time working in IT consulting, you already know this industry demands a lot from you—your time, your focus, your expertise, and sometimes your sanity. After several years working across different service companies, I’ve learned that one of the hardest skills isn’t configuring a system or solving a complex security issue… It’s learning how to say no.

We don’t like disappointing others. So instead of saying “no,” many of us default to:
“Happy to help… but can I get back to you later?”

It feels polite. It buys time.
But it still creates an expectation—and that expectation becomes your burden.

In this blog post, I want to explore the hidden cost behind the words yes, no, and maybe, especially for IT consultants. More importantly, I want to help you find a sustainable middle ground that protects your health, your relationships, and your long‑term career value.

Why Saying “Yes” Feels Natural—But Isn’t Always Healthy

As consultants, we’re conditioned to deliver. We want to grow experience, increase our market value, and be recognised as the person who gets things done. But companies also notice this… and some will happily take advantage of it.

👍 Pros of Saying Yes

  • Clients and colleagues love working with you.
  • You avoid negative perceptions or conflict.
  • The company saves money—no extra resources required.
  • If you work on commission, more work often means more income.
  • You may gain valuable experience, leading to future opportunities and higher salary potential.

👎 Cons of Saying Yes

  • Long hours become the norm.
  • Family time disappears—impacting relationships and even marriages.
  • If you’re not earning commission, you’re effectively doing unpaid work.
  • Quality drops when you’re stretched thin, harming your personal brand.
  • You prevent others (who may be underutilised) from getting work.
  • You lose time to upskill or stay current.
  • Your health suffers—stress, burnout, or worse.
  • Unrealistic expectations become “standard.”
  • Projects fail, customer relationships suffer, and it reflects on you.

When “No” Is the Healthiest Answer

Saying no doesn’t make you unhelpful—it makes you human. It sets boundaries and protects the quality of the work you do take on.

👍 Pros of Saying No

  • More time for family and personal life.
  • Higher quality deliverables.
  • Time to learn, grow, and improve skills.
  • A healthier lifestyle and stronger mental health.
  • More realistic expectations from employers and clients.
  • Better project outcomes and repeat customers.

👎 Cons of Saying No

  • Some people won’t like your response.
  • It may strain relationships with those who expect constant availability.
  • You might be passed over for future work by those who can’t handle boundaries.

The Trap of “Maybe”

Saying “maybe” feels safer than a direct no. But it often creates ambiguity that leads to stress on both sides.

👍 Pros of Saying Maybe

Everything is a “maybe” benefit:

  • Maybe you keep family time.
  • Maybe your work stays high quality.
  • Maybe you maintain reasonable expectations.
  • Maybe your project succeeds.

And that uncertainty is exactly the problem.

👎 Cons of Saying Maybe

  • Stress of giving an answer that isn’t really an answer.
  • Customers hear “not now” but expect “next week.”
  • You still end up working extra hours.
  • Family time still gets sacrificed.
  • The quality of your work still drops.
  • You still do unpaid work if you’re not on commission.
  • It still takes work away from others.
  • You still lose upskilling time.
  • Your health still suffers.
  • “Maybe” becomes the new expectation… also unrealistic.
  • Projects still fail, customers still leave.

If you look closely, the “maybe” list has nearly all the same cons as saying yes, minus the clarity.

Conclusion: How to Protect Your Career and Your Life

Achieving work–life balance as an IT consultant isn’t about choosing between yes, no, or maybe. It’s about strategic control—saying yes to the right things, no to the wrong things, and rarely using maybe at all.

Here’s how you can build a sustainable balance:

1. Set Clear Boundaries Early

People treat you based on what you allow. Set realistic expectations at the start of every project. Reinforce them.

2. Prioritise High‑Value Work

Not everything deserves your attention. Focus on tasks that grow your skills, enhance your market value, or meaningfully contribute to the project’s success.

3. Learn to Say “No, but…”

A powerful technique:

“No, I can’t take that on right now—but here’s what I can do.”

Offer alternatives: suggest timelines, other team members, or phased approaches.

4. Protect Your Non‑Work Time

Your health, family, and personal interests matter more than any project. Block out personal time the same way you block meetings.

5. Track your workload honestly

If you’re consistently overworked, it’s not a badge of honour—it’s a system that needs fixing.

6. Communicate openly

Clients and colleagues appreciate transparency. Clear communication avoids misunderstandings and prevents impossible workloads.

7. Remember: Your Career Is Yours—Not the Company’s

Companies benefit when you say yes. You benefit when you manage your yes carefully.

Okta AD Integration with Azure AD Domain Services

Posted on by Alan Schmarr

1. Introduction

This is a experimental article, using a existing Azure Active Directory (AD) and Azure Active Directory (AD) Domain Services deployment and integrating it with a Okta solution.

2. Preparation tasks

3. Assumptions

The following assumptions are made in following this article:

  • Windows 2012 R2 Member server of the  Azure AD Domain Services
  • The member server has internet access
  • Okta free trail without any modifications made

 

4. Installation

4.1 Create Service Account in Azure AD

  1. Log into Azure AD, Go to Users and Click “ADD USER“
  2.  In “Type of user“, Choose “New user  in your organization“
  3. In “User Name”, Use company Service Account Name convention e.g. okta
  4. okta6
  5. In “First Name“, “Last Name” and “Display Name“, Enter Okta
  6. In “Role”, Choose “User”
  7. Create a temporary password, and document the password for next step.
  8. Go to http://portal.office.com, Login as the new user and set the password.
  9. The default password expiry is set on the account and should be disabled by using Azure AD PowerShell.

4.2 Okta AD Agent Install

Please follow theses steps for integrating Azure AD Domain services with Okta:

  1. Log onto the Domain joined Server that will run the Okta Agent
  2. Go to your okta administrator url e.g. https://<Company>-admin.okta.com/admin/dashboard
  3. On the top navigation bar, go to Security, Authentication
  4. okta1
  5. Click “Configure Active Directory“
  6. okta2
  7. Click, “Set Up Active Directory“
  8. okta3
  9. Click, “Download Agent“
  10. okta4
  11. Once the agent is finished downloading, run the installation.
  12. In the Welcome screen, Click “Next“
  13. okta5
  14. Choose the path for the installation and click “Install“
  15. In The Domain field, enter company domain and click “Next” e.g. schmarr.com
  16. Choose “Use an alternate account that I specify“
  17. Enter username and password and click “Next“
  18. At Okta AD agent Proxy Configuration, Click “Next“
  19. At Register Okta AD Agent, Choose Production and in “Enter Subdomain” add company name.
  20. Click “Next“
  21. Sign in with your Okta Admin Account
  22. Click “Allow Access“
  23. Agent Installed, Click “Next”
  24. As an Example choose the following in “Basic Setting“
  25. okta7
  26. Click “Next“
  27. Click “Next“
  28. In “Select the attributes to build your Okta User profile“, Click “Next“
  29. Done
  30. okta8

Conclusion

The ability to add SaaS applications in Azure AD and Okta, Azure AD being the Identity store for both.

Integrate SharePoint with Azure AD

Posted on by Alan Schmarr

1. Introduction

This article will show the quick configuration tasks, that are required to make Azure AD a trusted identity provider for a SharePoint 2013 installation.

2. Assumptions

The following assumptions are made during this article:

3. Preparation

Before starting with the article the following needs to be in place:

  • Azure AD PowerShell tools installed, look here for more details.

4. Configuration

The configuration will be broken into the following sections:

  • Azure AD configuration
  • SharePoint configuration
  • Assigning Users

4.1 Azure AD Configuration

Follow these tasks to document the Azure AD WS-Federation metadata URL for later use:

  1. In the Azure Management Portal (Classic), Click Active Directory.
  2. Click on the Azure AD that will be integrated with SharePoint 2013
  3. Click Applications
  4. On the bottom bar, Click View Endpoints
  5. Document the Federation metadata document url for later use

Follow these tasks to create / configure the namespace in Azure AD :

  1. In the Azure Management Portal (Classic), Click Active Directory.
  2. Click Access Control Namespaces, and create a new namespace and called it “Company”
  3. Click Manage on the bottom bar. This should open https://company.accesscontrol.windows.net/v2/mgmt/web.
  4. Click Identity Providers, Click Add
  5. Click WS-Federation identity provider, click Next.
  6. In Displayname enter, “Company”
  7. In Login link Text enter, “Company”
  8. In WS-Federation metadata, choose URL and enter the URL that was documented in tasks above Example: https://accounts.accesscontrol.windows.net/company.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml
  9. Click Save
  10. Click Relying party applications, then click Add
  11. Enter the following in each field:
    1. Name: “Company SharePoint”
    2. Realm: “urn:sharepoint:company”
    3. Token format: SAML 1.1
    4. Token lifetime (secs) default is 600: Recommended value is 2 hours
  12. Click Save
  13. Click Rule Groups, and then Add
  14. Click Generate
  15. Click Add
  16. Fill in all the fields as illustrated below:
  17. The claim rules in Azure Access Control
  18. Click Save
  19. Delete the existing claim rule named upn
Extract the X.509 certificate from Azure Access Control for later use
  1. In the Access Control Service pane, under Development, click Application integration.
  2. In Endpoint Reference, locate the Federation.xml that is associated with your Azure tenant, and then copy the location in the address bar of a browser.
  3. In the Federation.xml file, locate the RoleDescriptor section, and copy the information from the <X509Certificate> element, as illustrated in the following figure.
  4. X509 Certificate element of Federation.xml file
  5. from the root of drive C:\, create folder named Certs
  6. Save the X509Certificate information using notepad to the folder C:\Certs and name the file ACS.cer
  7. Run the following PowerShell commands:
    1. “Connect-MsolService”
    2. “Import-Module MSOnlineExtended -Force”
    3. $replyUrl = New-MsolServicePrincipalAddresses -Address “https://company.accesscontrol.windows.net&#8221;
    4. “New-MsolServicePrincipal -ServicePrincipalNames @(“https://company.accesscontrol.windows.net&#8221;) -DisplayName “Company ACS Namespace” -Addresses $replyUrl”

4.2 SharePoint 2013 Configuration

Follow these steps to configure Azure AD as the identity provider for SharePoint 2013:

  1. From the Start menu, click All Programs.
  2. Click Microsoft SharePoint 2013 Products.
  3. Click SharePoint 2013 Management Shell
  4. Run the following PowerShell commands:
    1. $root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\Certs\ACS.cer”)
    2. New-SPTrustedRootAuthority -Name “Token Signing Cert Parent” -Certificate $root
    3. $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\Certs\ACS.cer”)
    4. New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $cert
    5. $map1 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&#8221; -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming
    6. $map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname&#8221; -IncomingClaimTypeDisplayName “GivenName” -SameAsIncoming
    7. $map3 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname&#8221; -IncomingClaimTypeDisplayName “SurName” -SameAsIncoming
    8. $map4 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role&#8221; -IncomingClaimTypeDisplayName “Role” -SameAsIncoming
    9. $realm = “urn:sharepoint:company”
    10. $signInURL = “https://company.accesscontrol.windows.net/v2/wsfederation&#8221;
    11. $ap = New-SPTrustedIdentityTokenIssuer -Name “ACS Provider” -Description “SharePoint secured by SAML in ACS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1,$map2,$map3,$map4 -SignInUrl $signInURL -IdentifierClaim “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&#8221;
  5. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.

    In Central Administration, on the home page, click Application Management.

  6. On the Application Management page, in the Web Applications section, click Manage web applications.
  7. Click the appropriate web application.
  8. From the ribbon, click Authentication Providers.
  9. Under Zone, click the name of the zone. For example, Default.
  10. On the Edit Authentication page, in the Claims Authentication Types section, select Trusted Identity provider, and then click the name of your provider, which for purposes of this article is ACS Provider. Click OK.
  11. The following figure illustrates the Trusted Provider setting.
The Trusted Provider setting in a web app

4.3 Assigning Users

Use the following steps to set the permissions to access the web application.

  1. In Central Administration, on the home page, click Application Management.
  2. On the Application Management page, in the Web Applications section, click Manage web applications.
  3. Click the appropriate web application, and then click User Policy.
  4. In Policy for Web Application, click Add Users.
  5. In the Add Users dialog box, click the appropriate zone in Zones, and then click Next.
  6. In the Add Users dialog box, type user2@company.onmicrosoft.com (ACS Provider).
  7. In Permissions, click Full Control.
  8. Click Finish, and then click OK.

Conclusion

Azure AD is the trusted identity provider for SharePoint 2013, and Azure AD users will be able to authenticate and use SharePoint 2013 resources.

External Links

Some good extra reading articles:

 

 

Quick Install Guide For SharePoint Foundation 2013

Posted on by Alan Schmarr

1. Introduction

This quick install guide will assist in installing SharePoint foundation 2013 server to address certain technical / business requirements. This type of installation will have some limitations and might not be fit for production deployments.

2. Preparation Tasks

The following preparation tasks will be required before starting the SharePoint 2013 Foundation installation:

3. Assumptions

The following assumptions are made during the creation of this article:

  • Active Directory or Azure AD Domain Services is up and running
  • Active Directory Member server, running windows 2012 R2
  • Unrestricted internet access
  • SSL Certificate is available for site.
  • Experience in SSL certificates
  • Access to DNS Server to create records

    If using Azure AD Domain Services, changing DNS record will not be allowed.

2. Installation

The installation is broken up into two parts:

  1. Framework installation
  2. Configuration

2.1. Framework installation

  1. Run the “sharepoint.exe” that was downloaded in the preparation tasks
  2. SharePoint2013Screenshot1
  3. Click “Install software prerequisites“
  4. Click “Next“
  5. Check “I accept the terms of the License Agreement(s)“
  6. Click “Next”

    The process will install all required roles and software, during the installation the server will be reboot twice, logon with the same user account that was used to continue installation.

  7. Run the “sharepoint.exe” that was downloaded in the preparation tasks
  8. SharePoint2013Screenshot1
  9. Click “Install SharePoint Foundation“
  10. Choose “Stand-alone” installation
  11. Click “Install Now“
  12. Check “Run the SharePoint Products Configuration Wizard now.“
  13. On the Welcome Screen, Click “Next“
  14. On warning dialog, Click “Yes“
  15. Click “Finish“

2.2 Configuration

Once the steps above have completed, SharePoint foundation will be installed and running. Users will be able to connect to the default SharePoint Team Site, by using http://<servername&gt; URL.

To change the default URL to the required URL, follow these steps:

  1. Import SSL certificate into local computer store
  2. Open “SharePoint 2013 Central Administration“
  3. Under “System Settings“, Click “Configure alternate access mappings“
  4. Click “Edit Public URLs“
  5. In “Alternate Access Mapping Collection:” list, choose “SharePoint – 80“
  6. In “Default“, Change http://<servername&gt; to https://<newURL&gt; e.g. https://sharepoint.company.com

IIS Manager Configuration

The following task should be done on IIS Manager to allow the configuration changes:

  1. Open “Internet Information Services (IIS) Manager” console
  2. Go to <SERVERNAME>\Sites\, click  “SharePoint – 80“
  3. On the right hand site, click “Bindings…“
  4. Click “Add…“
  5. In Type, choose “HTTPS“
  6. In Host name, enter the new dns address e.g. sharepoint.company.com
  7. In SSL certificate, choose the imported SSL certificate
  8. Click “OK“
  9. Remove “http” binding
  10. Click “Close“

User’s should be able to use the new secure URL to access the SharePoint team site. e.g. https://sharepoint.company.com

P.S. Make sure to include the new URL into user Internet Explorer local intranet zones

Conclusion

Basic SharePoint 2013 foundation team site will be running and available for business, the solution will be using windows internal database and have some limitations.

 

 

AD CS Install Guide For Azure AD Domain Services

Posted on by Alan Schmarr

1. Introduction

Active Directory Certificate Services (AD CS) provides customizable services for issuing and managing public key certificates used in software security systems that employ public key technologies.

Azure AD domain Services allows limited access to the Active Directory instance for administrators, only a standalone Certificate Authority (CA) deployment will be possible.

More information about AD CS can be found here.

2. Assumptions

The following assumptions are made during the creation of this article:

  • Azure AD Domain Services is up and running
  • Active Directory Member sever, running windows 2012 R2
  • Experienced in Microsoft Certificate Authority
  • Experienced in Active Directory

3. Installation

Please follow the instruction below to install a Standalone CA:

Disclaimer:

This is a quick and basic installation and should be evaluated if it meet business and security requirements.

  1. Run the following PowerShell Command as Administrator
    1. “Install-WindowsFeature AD-Certificate,ADCS-Cert-Authority,ADCS-Web-Enrollment -IncludeManagementTools“
  2. Run the following PowerShell command as Administrator
    1. “Install-AdcsCertificationAuthority -CAType StandaloneRootCa“
  3. Run the following Powershell command as Administrator
    1. “Install-AdcsWebEnrollment“

4. Configuration

After the completion of section 3, the AD CS service should be up and running with default configuration. Here is some recommendation for making the AD CS more secure and a production ready service.

Steps to import the Root CA as trusted authority for all domain joined Servers/ machines.

  1. Download Root CA:
    1. Go to http://<Servername>/certsrv
    2. Click “Download a CA certificate, Certificate chain, or CRL”
    3. Click “Download CA certificate”
    4. Save the file for next steps
  2. Open Group Policy Management (Follow below to install Group Policy Management on a Member Server)
    1. Run the following PowerShell Command as Administrator
      1. “Install-WindowsFeature GPMC“
  3. Edit “AADDC Computers GPO“
  4. Go to “Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities” section
  5. Import the Root CA into the section above
  6. Close the Group Policy
  7. To allow the group policy to take affect:
    1. reboot member servers, or
    2. run “gpudpate /force” as administrator

5. Conclusion

Azure AD domain Services domain joined servers will be able to install and trusted the new standalone CA Certificates.

 

 

Azure AD Domain Services Quick Install

Posted on by Alan Schmarr

Introduction

Azure Active Directory Domain Services lets you join Azure virtual machines to a domain without the need to deploy domain controllers, more detail can be found here.

This article show quick way to install and configure Azure AD Domain Services, other options might be required for a production deployment and not highlighted in this article.

At the time of writing this article most of the configuration will be done in Azure Portal (Classic), Microsoft is planning to move everything to the new Azure portal.

Assumptions

The following assumptions are made in this article:

  • Functional Azure AD – A quick guide can found here
  • Access to Azure Subscription

Preparation Tasks

The following preparation tasks will be required before starting the installation process below:

Installation

This section will be divided into the following sections:

To create all the required Azure resources, please follow the steps below:

1. Azure Virtual Network

  1. Go to https://manage.windowsazure.com
  2. Click “+ NEW”
  3. AzureADDomainServices5.JPG
  4. Click “Network Services“, “Virtual Network” and then click “Custom Create“
  5. AzureADDomainServices6
  6. In Name, enter required network name
  7. Choose correct Location
  8. AzureADDomainServices7
  9. On Page 2, leave DNS servers empty for now
  10. On Page 3, enter the required Address space range and Subnets for the network
  11. AzureADDomainServices8
  12. Click check mark to create network

2. Create ‘AAD DC Administrators’ Group

To allow users to manage Azure AD Domain Services, you’ll first need to create a group in Azure AD called ‘AAD DC Administrators’ and add all the users that should have admin rights.

For more detailed tasks, please have a look here.

3. Azure AD Domain Services

  1. Go to https://manage.windowsazure.com/
  2. On the left Menu find, “ACTIVE DIRECTORY“
  3. Click on the required Azure AD in the list provided
  4. AzureADDomainServices9
  5. Click “CONFIGURE” tab
  6. Scroll down and find “domain services” section
  7. Change “ENABLE DOMAIN SERVICES FOR THIS DIRECTORY” to “YES“
  8. Change “DNS DOMAIN NAME OF DOMAIN SERVICES” to required suffix
  9. Choose the network that was create in steps above for “CONNECT DOMAIN SERVICES TO THIS VIRTUAL NETWORK“
  10. Click “Save“
  11. The creation might take a bit of time to complete, once completed DNS server IP addresses will be provided for use in the created Virtual Network. (Please follow steps below to finish Virtual Network configuration)

3. Configure Azure Virtual Network DNS Servers

  1. Go to https://manage.windowsazure.com/
  2. On the left Menu find, “ACTIVE DIRECTORY“
  3. Click on the required Azure AD in the list provided
  4. AzureADDomainServices9
  5. Click “CONFIGURE” tab
  6. Scroll down and find “domain services” section
  7. Document the IP Addresses in “IP ADDRESS” section for next steps
  8. AzureADDomainServices10
  9. On Left hand menu, Choose “NETWORKS“
  10. Open the network that was created and have been enabled for Azure Domain Services
  11. Click “CONFIGURE“
  12. In the “dns servers” section, enter the two dns servers documented in previous step
  13. Click “SAVE“

 

Before using Azure AD domain services, please follow this guide to enable password synchronization.

Conclusion

By the end of this guide Azure AD domain services will be functional with the ability to domain join Azure Virtual machines.

Filtering on Azure AD Connect

Posted on by Alan Schmarr

Introduction

This article will add a filter for Azure AD Connect for only syncing user accounts that have a valid email address. Additional options may be required by the organization and more detail can be found here.

Preparation Tasks

The following tasks should be completed before starting the process:

  1. Azure AD Connect is installed and configured – see “Getting Started with Azure AD Free Edtion“
  2. Administrator Access for Azure AD Connect Server

Adding the Filter

The following tasks should be preformed on the Azure AD Connect Server:

Disable scheduled task

To disable the scheduled task which will trigger a synchronization cycle every 3 hours, follow these steps:

  1. Start Task Scheduler from the start menu.
  2. Directly under Task Scheduler Library find the task named Azure AD Sync Scheduler, right-click and select Disable.
    Task Scheduler
  3. You can now make configuration changes and run the sync engine manually from the synchronization service manager console.

After you have completed all your filtering changes, don’t forget to come back and Enable the task again.

  1. Open “Synchronization Rules Editor“
  2. Click “Inbound“
  3. FilteringAzureADScreenShot1
  4. Find “In From AD – User Join” rule, click “Edit“
  5. FilteringAzureADScreenShot2
  6. Click “Yes“
  7. In “Precedence“, enter “500“
  8. Click “Next“
  9. Only include user that a have email address
    1. Click “Add clause“
    2. Attribute Field choose “mail“
    3. Operator field choose “ISNOTNULL“
    4. FilteringAzureADScreenShot4
  10. Add Company email domain (Optional – checking if user have a email address solves most cases)
    1. This rule assumes you only have one email domain, will not work for multi-domain
    2. Click “Add clause“
    3. Attribute Field choose “mail“
    4. Operator field choose “ENDSWITH“
    5. Value enter “<email>.<domain-name>”
    6. FilteringAzureADScreenShot5
  11. Apply and Verify changes
  12. Enable Scheduled task

Conclusion

Completion of this article, the organization will only sync user accounts that have a valid email address into Azure AD.

 

 

 

Getting Started with Azure Active Directory Free Edition

Posted on by Alan Schmarr

 Introduction

Azure Active Directory (Azure AD) is Microsoft’s multi-tenant cloud based directory and identity management service.

More in-depth detail about Azure AD can be found here.

The article illustrate the registration process and the essential configuration tasks for Azure AD free edition for use of organization internal users. (Future posts will look at other scenarios)

Preparation tasks

The follow preparation tasks will be required:

  1. Have a Microsoft account ready to use for sign-up;
    1. Generate a Microsoft account by going here;
    2. Follow the on-screen wizard and complete sign-up;
  2. A credit Card – This will only be used for verification and not be charged unless you explicitly upgrade to a paid offer;
  3. Optional – External Domain Name e.g. schmarr.com to integrate into Azure AD;
    1. P.S. You’ll need to be able to create TXT records in the external domain.

Installation

Registration

Please follow theses steps in registering your free Azure subscription that will host Azure AD:

  1. Go to the following url: https://azure.microsoft.com/en-us/trial/get-started-active-directory/;
  2. Click on “Create a free Azure Account”;
  3. Click “Start Now”;
  4. Fill in the form and submit;
  5. The subscription will take up to 4 minutes to be created.
  6. Once the process is complete you should see the following screen:

AzureADFree-ScreenShot1

By now a default Azure AD is already created, skip “Create Azure AD” section if default instance shouldn’t be used.

Create Azure AD (Optional)

Follow the these steps to create a new Azure AD:

  1. In the left corner click on the “+ New” icon
  2. Click “Security + Identity”
  3. Click “Active Directory”
  4. It will re-direct to the Azure Classic portal (This might change in the future)
  5. You will get the following Wizard
  6. AzureADFree-ScreenShot2
  7. Fill in the form and click the check to create the Azure AD

Essential Azure AD Configuration

At this point Azure AD is fully functional, with the following constraints:

  • Manual process is required for creating user accounts (GUI, PowerShell or CSV import);
  • User passwords will not be in-sync with their network passwords;
  • Usernames at this stage will be <username>@<AzureADName>.onmicrosoft.com;
    • Users will be required to remember their usernames. (Most users find it difficult remember their password);

Follow my Essential Azure Configuration guide here if you want to address the constraints mentioned above.

Conclusion

After completion of this guide, Azure AD free edition will available and be functional with available features.

Essential Azure AD Configuration

Posted on by Alan Schmarr

Introduction

Azure Active Directory (Azure AD) is Microsoft’s multi-tenant cloud based directory and identity management service.

More in-depth detail about Azure AD can be found here.

a fresh Azure AD installation will have the following constraints:

  1. Usernames at this stage will be <username>@<AzureADName>.onmicrosoft.com;

    Users will be required to remember usernames. (Most users find it difficult remember their passwords);

  2. Manual process is required for creating user accounts (GUI, PowerShell or CSV import);
  3. User passwords will not be in-sync with their network password;

This article will only focus in addressing the constraints above, with the least possible effort. More complex options are available and will depend on security & business requirements.

Configuration / Installation

Each optional tasks below should be followed chronological order to address the constraints above.

1. Add Email Domain (Optional)

This step should be done first before proceeding with step 2.

Only one Azure AD can own the organization email domain and Microsoft will not allow registering the email domain into another Azure AD Subscriptions.

Follow these steps to allow usernames to be the same as the organization email address:

  1. Go to https://manage.windowsazure.com
  2. On the left menu click “Active Directory”
  3. Open your new create Azure AD, you should see the following screen:
  4. AzureADFree-ScreenShot3
  5. Click “Domain” Tab
  6. Click “ADD A CUSTOM DOMAIN”, the following wizard will appear:
  7. AzureADFree-ScreenShot4
  8. Enter company domain name, example: “schmarr.com”, click “add”
  9. On Page 2, will have the TXT record that should be created in the company domain external DNS service. Please see example:
  10. AzureADFree-ScreenShot5
  11. Once the DNS TXT record is created, Click “verify” (Please allow DNS replication to complete up to 48 hours)
  12. Change the user accounts manually to reflect user emails addresses

    For automating user creation and password sync, please proceed to step 2.

2. Automate Account creation in Azure AD (Optional)

It is recommended that step 1 should be completed first, otherwise all users account will be created with system created domain name e.g. “<username>@<AzureADName>.onmicrosoft.com”

Assumptions / Requirements

The following assumptions are made in this section:

  • Internal Active Directory up and running
  • Windows 2012 R2 Member server of the Active Directory, ready to install Azure AD Connect
  • The member server has internet access
  • Active Directory userPrincipalName(UPN) reflects the user’s mail address
    • This assumption is in most cases are a challenge for most organizations and the following options are available:
      • Run the Azure AD Connect (Steps below is expert install) in advanced mode and choose “mail” attribute instead of userPrincipalName(UPN) – Easy fix;
      • Fix the UPN to be the same as email address, here is a microsoft tool that can assist;
  • Azure AD
  • A Active Directory enterprise administrator account
  • global admin account is created with default domain context e.g. admin@<AzureADName>.onmicrosoft.com

Azure AD Configuration

  1. Go to https://manage.windowsazure.com
  2. On the left menu click “Active Directory”
  3. Open your new create Azure AD, you should see the following screen:
  4. AzureADFree-ScreenShot3
  5. Click “DIRECTORY INTEGRATION” Tab
  6. Click “ATIVATED”, then click “SAVE”

Azure AD Connect Installation

The following tasks will be completed on the domain member server.

  1. Download Azure AD Connect from Here
  2. Run the downloaded setup file on the Windows 2012 R2 member server
  3. Click “Continue”
  4. Click “Use express settings”
  5. Enter your Azure AD Admin username e.g. admin@<AzureADName>.onmicrosoft.com and password
  6. Click “Next”
  7. Enter the Active Directory Enterprise Admin account and password
  8. Click “Next”
  9. Click “Install”
  10. AzureADFree-ScreenShot6

Once the installation is complete all user accounts will be created in Azure AD automatically with the current user email address. Password synchronization will also be automatically enabled.

Advanced installation will allow disabling password sync if not required.

Conclusion

User will be now be able to login into Azure AD using exiting email address and network password.

 

 

 

ADFS 2016 Technical Preview 4 Install Guide

Posted on by Alan Schmarr

Introduction

Microsoft is in the process of releasing a new version of Windows Server 2016, with this new release it will include and new version of ADFS.

In this article I will be only focusing on the installation process of ADFS 2016 preview (The easy bit), future guides will have more focus on integration.

Here is also some related reading material from my previous posts:

  • Group Managed Service Accounts – This is highly recommended for all ADFS implementations. This article was written on 2012 but still relevant for 2016.

My Lab

The lab is running in Microsoft Azure, the following relevant services for ADFS 2016 is running in this lab:

  • Active Directory – Single Forest, Single Domain
    • OS – Windows 2012 R2
    • Server Name – DC2012R2
  • PKI Certificate Server running on the domain controller (Not a recommended for production)
  • ADFS 2016 Backend Server
    • OS – Windows 2016 Technical Preview 4
    • Server Name – S2016PR4ADFS01
  • ADFS 2016 Web Applications Proxy Server
    • OS – Windows 2016 Technical Preview 4
    • Server Name – S2016PR4PRX01

Preparation

All ADFS implementation will require the following high-level preparation tasks before starting with the installation: (Microsoft has a well documented checklist that should be follow)

  • Split Brain DNS – This allows internal users to resolved the ADFS URL to the Internal ADFS backend servers. Info can be found here.
  • DNS records
    • External DNS
      • A Record – adfs2016.schmarr.com
        • Point to Web Application Proxy Server external IP
      • A Record – enterpriseregistration.schmarr.com
        • Point to Web Application Proxy Server external IP
      • A Record – certauth.adfs2016.schmarr.com
        • Point to Web Application Proxy Server external IP
    • Internal DNS
      • A record – adfs2016.schmarr.com
        • Point to ADFS 2016 backend server internal IP
      • A Record – enterpriseregistration.schmarr.com
        • Point to ADFS 2016 backend server internal IP
      • A Record – certauth.adfs2016.schmarr.com
        • Point to ADFS 2016 backend Server internal IP
  • ADFS features – ADFS has additional feature which needs to be consider before proceeding in acquiring the required certificate for encryption. e.g. workplace join have some additional requirements for the certificate, Read more about workplace join here.
  • Certificate – All ADFS communication between the client and ADFS is encrypted, so the certificate should be trusted by all parties. A External Certificate is advised.
    • In this article a internal certificate was used.
    • Lab SSL Certificate attributes:
      • Subject Name (CN): adfs2016.schmarr.com
      • Subject Alternative Name (DNS): adfs2016.schmarr.com
      • Subject Alternative Name (DNS): enterpriseregistration.schmarr.com
  • Group Managed Service Account  – how-to
    • Enable Managed Service Accounts (On Domain Controller running 2012 R2 or higher)
    • ADFSGmsa
      • Powershell command  – “New-ADServiceAccount ADFSGmsa -DNSHostName adfs2016.schmarr.com -ServicePrincipalNames http/adfs2016.schmarr.com”
  • Topology – Choose the correct topology to fit business requirements. More information about topologies can be found here.
    • Stand-Alone Federation Server using WID (Windows Internal Database) will be used in this article.
      • Gotcha – Limit memory usage for WID

Installation

ADFS 2016 backend server installation

  1. Install the required SSL certificate.
    1. Here is a guide for requesting a SAN certificate for internal PKI or External certificate provider.
    2. ADFS2016Preview-ScreenShot2
    3. Additional information for the “certauth” url can be found here
  2. Install Active Directory Federation Services role on server
    1. Powershell command – “Install-windowsfeature adfs-federation –IncludeManagementTools“
    2. Get the 2012 R2 wizard options from here
  3. Configure Active Directory Federation Services
    1. Powershell command – “Install-AdfsFarm -CertificateThumbprint ff236398ad5b51b9dd427cf819e6586b43d2009b -FederationServiceName adfs2016.schmarr.com -GroupServiceAccountIdentifier AS\ADFSGmsa$“
    2. Get the 2012 R2 wizard options from here
  4. Limit WID memory usage
    1. Install SQL Management Studio Express – Download from here
    2. Open admin Command prompt – “osql -E -S \.pipeMICROSOFT##WID“
    3. Enter the following commands
      1. exec sp_configure ‘show advanced option’, ‘1’;
      2. reconfigure;
    4. To check current config:
      1. exec sp_configure;
      2. go
    5. Reconfigure to use 2GB
      1. exec sp_configure ‘max server memory’, 2048;
      2. reconfigure with override;
      3. go
      4. quit
    6. Restart the Windows Internal Database service
    7. Optional – Uninstall SQL Management Studio Express
  5. Testing Installation
    1. Powershell command – “Set-AdfsProperties -EnableIdPInitiatedSignonPage $true“
    2. Go to the following url https://adfs2016.schmarr.com/adfs/ls/IdpInitiatedSignOn
      1. User should be able to sign-in from domain joined machine on the internal network
      2. User should be able to sign-in from non domain joined machine on the internal network
    3. Optional – Disabled IdPInitiatedSignonPage
      1. Powershell command – “Set-AdfsProperties -EnableIdPInitiatedSignonPage $false“

 ADFS 2016 Web Application Proxy Server installation

  1. Export the certificate from the ADFS backend server with private key
  2. Import into computer store of Web Application proxy server
  3. Install Web Application Proxy Role
    1. Powershell Command – “Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools“
    2. Get the 2012 R2 wizard options from here
  4. Configure Web Application Proxy Role
    1. Powershell Command – “Install-WebApplicationProxy –CertificateThumbprint ‘‎ff236398ad5b51b9dd427cf819e6586b43d2009b’ -FederationServiceName adfs2016.schmarr.com“
    2. Get the 2012 R2 wizard options from here
  5. Testing Installation
    1. On ADFS backend Server run Powershell command – “Set-AdfsProperties -EnableIdPInitiatedSignonPage $true“
    2. Go to the following url https://adfs2016.schmarr.com/adfs/ls/IdpInitiatedSignOn
      1. User should be able to sign-in from domain joined machine on the external network
      2. User should be able to sign-in from non domain joined machine on the internal network
    3. Optional – Disabled IdPInitiatedSignonPage
      1. Powershell command – “Set-AdfsProperties -EnableIdPInitiatedSignonPage $false“

Conclusion

This article demonstrated installing ADFS 2016 preview 4 in a Stand-Alone Federation Server using WID topology.