Introducing Azure AD Join and Domain Services

As we know, Windows 10 became available in August with a lot of benefits to our customers, and with “him”, several cloud changes were been questioned. In the near future, Microsoft Azure will assume a crucial role at most of global organizations, and even the most skeptical IT decision makers will be surrounded to their benefits and felt excited with that.

Azure AD consists on a directory behind Office 365 and Intune subscriptions. So, if we want to manage Windows 10 devices (Laptops, Surfaces..) through Azure AD, we’ve two options:

• Azure AD Join
• Workplace Join

These two options have distinct goals. Let take a quick dive on it.

Let me start with the Workplace Join. Resuming, consists on a feature built natively for Windows 8.1, which allow users to access to specific identified corporate services and resources. Was been improved for Windows 10, and allow the employee who uses their personal phone (or computer, or tablet,…) to extend its (or their) functionalities. Basically, consists in a high-level trust mechanism established between organization and employee. The resource (phone, computer, tablet,…) will be represented on the Azure AD and provides to IT an assessment view and reporting, but as expected, provide only few actions and control about them. Is directly built and designed for BYOD scenarios.

In the other hand, if your IT dept. are distributing provisioned Windows 10 devices to employees which will have mainly accesses to Office 365, web apps (deployed through “My Apps” portal) and other “cloud-based” resources, the Azure AD Join should be your choice. Provide several gains to the prior one including the Windows 10 login with Azure AD accounts/credentials and the Single-Sign-On for cloud-based (and On-Premises) services and resources. In addition, provide a crucial improvement – providing the native Microsoft Intune enrollment during its join.

It’s impossible not talk (or write in this case) about the Domain Services of Azure AD, which is currently in Preview and released recently by Microsoft. Domain Services is still a «baby» and according to that fact, will grow significantly for sure in the next weeks, which in fact can have some risks if you’re considering this implementation in a short period. Despite of that, Domain Services provide the possibility to consuming local Group Policy Objects (GPOs) and deploy them via Azure AD, or to create new ones (and deploy them of course). The main goal will be achieved: manage all supported devices through the cloud just as your doing now On-Premises. Additionally, Domain Services will integrate natively with the current Azure tenants (could it be in a different way?).

Let me share some deep sources about it Azure AD Join and Azure AD Domain Services.

Enjoy Azure AD!

/ Fabio

Azure AD – Introducing SaaS plus MyApps Portal

As we know, Azure Active Directory has many benefits and we can see all of them on this link.

This post intends to share all required steps to bring the new concept (or feature) from Azure AD into organizations – SaaS.

Azure AD introduces SaaS (Software as a Service), which in a very high-level view, consists on a new way to deliver Apps to your employees without the old installation concept requirements.

There are three editions of Azure AD: Free, Basic and Premium. Once we’re running a lab, we can use the Premium (for 1month), but if you’re looking for a production environment, the good new is that the SaaS feature is supported for all of Azure editions. But (there’s always a «but») excepting the Premium, for Free and Basic editions is already limited for 10 applications per user. So, IT Admins can configure as many applications they want (with or without Single Sign-On), but each user will see only up to 10 Apps on their “My Apps panel”). This feature is better known and described as Group based application access.

To get more info check this very extended info.

Real Challenge

So, for this post I’ll share my experience and a recurrent request/concern about many customers nowadays. Your company has its own Twitter account which should be managed by the Marketing dept. to publish news, to share some reports and so on. But the main concern for many IT departments consists on that question: How many ways do they have to manage it? I’ll try a few some ways:

1. Give/share the corp Twitter account logon to all Marketing members?
2. Give/share the corp Twitter account logon to some Marketing “key” member?
3. Do not give corp Twitter account to anyone.

I assume that the third option would be chosen by all. For those who choose that third option, I have good news. That’s possible with Azure AD!

Above, I’ll post a step-by-step guide to publish one application through Azure Portal, and the consequent access by Microsoft “My Apps” Portal.

Step-by-step guide

1. Create the test Group/User

On your Active Directory On Premises, create a Marketing Global and Security group.

Then create a test user. Don’t forget to assign the user logon name for <customized_tenant>.

Assign the previous created user to the previous created group.

Wait for the sync or set it manually. How? This post will help you.

2. Add Azure Application

Once this will be published through the Azure AD Management Portal, access it with your @outlook.com account.

Never forget: For Azure Management Portal, you’ll access it with a Microsoft Live ID account.

Follow the path: “Azure Active directory > «tenant_directory» > Applications”

Select the “Add” option on the bottom.

On the screen, check “Add an application from the gallery”. You can also publish LoB and external apps too.

Nowadays, Microsoft have more than 2500 available apps. You can choose whatever you want. For this example I’ll pick the Twitter app.

On the bottom, you’ll get the following message:

Once that the application is already added, you need to assign it to a specific group(s). Guess whom? Correct! The one created previously on this post!

Select the first option: “Configure single sign-on” and check “Password Single Sign-On”. Apply it.

To assign accounts, browse for “Marketing” previously created group with “Mike Smith” user as a unique member.

And click on the bottom option named “Assign”.

A prompt window will appear. On this, you’ll set the Twitter account credentials (including password). Through this way, Mike Smith doesn’t (and never won’t) know the “Enterprise twitter account”.

Apply it.

Close your browser session and ensure that the credentials won’t be saved (for the next opened session).

3. Access it through My Apps Portal

Open a new session and access to My Apps portal.

Enter the Mike Smith credentials.

And the user will get the “Twitter” app available with credentials included. Again, the user have no idea which credentials are being used. He just have access to the “authenticated” app.

Enjoy Azure AD!

/ Fabio

ConfigMgr and MS Intune lab creation – Here comes the end of the saga…plus the resume!

As promised, the (seven) previous posts can be a good starting point of Microsoft Intune.

Hope provide you all the required steps to build a laboratory to set a first experience on Intune and Config Mgr.

Once that the first saga becomes to the end, here it goes a few resume:

• Part I:
  • Azure and Intune Subscriptions;
• Part II:
  • Migrate AD On Premises to the cloud: Azure Active Directory Connect;
• Part III:
  • Configuring Config Mgr to support Microsoft Intune;
• Part IV:
  • UPN for Cloud Domain and Intune Licensing;
• Part V:
  • Step-by-step: Enroll of a Windows 8.1 device;
• Part VI:
  • iOS device Enrollment – Pre-requisites;
• Part VII:
  • iOS device enrollment – Step-by-step device guide;

As an Intune / Azure / Config Mgr enthusiastic, I’ll keep focused on these technologies, so… Stay tuned! 😉

/ Fabio

ConfigMgr and MS Intune lab creation – 4th Part | UPN for Cloud Domain and Intune Licensing

Keeping our focus the continue our MS Intune subscription integrated with Config Mgr lab, this post intends to share:

• AD “on-premises” customization to support “cloud” authentication;
• Setting Intune licenses management for groups automatically;

Since the users will be authenticated into the cloud with a different suffix that they have “on-premises”, we need to add the UPN of the cloud domain. This means that we need to add the <customizedtenant.onmicrosoft.com> on our AD “on-premises”.

To do that, use “Active Directory Domains and Trusts”.

Right click on the first left option, then select “Properties”.

On the only available tab – “UPN Suffixes” – add your <customizedtenant.onmicrosoft.com>.

Apply it.

Now, go to “Active Directory Users and Computers” and create a User. In my case I named it “intuneuser1”

On the “Account” tab, change the suffix of the “User logon name” (always known as UPN) to <customizedtenant.onmicrosoft.com> – set previously on this post.

This change is required to allow the user to authenticate into the cloud.

Set a password which will be replicated to the Azure AD.

Add it to the AD Group created specifically to Intune and used on the SCCM Collection also (see the previous post).

In my case, I named as “Intune” (I know, I’m not very creative).

We need to sync these changes right now.

You probably noticed that during Azure AD Connect installation, a Task Scheduler entry was been created. This Task Scheduler is responsible to handle all synchronizations between AD “on-premises” and Azure AD.

The schedule time by default is configured to synchronize both AD’s every 3hours, but is disabled by default as well. Once this is a lab, and never forgetting our focus as usual, we must enabled it, run it and disabled afterwards.

Note: Is always a good idea to check the log with the Azure Synchronization service > Operations and then check those changes through Azure AD Portal also.

Set licensing – Microsoft Intune

Access to Azure Management Portal.

Click Active Directory and select your tenant directory.

On the top bar, choose the last option: Licenses.

Click on “Intune A Direct”. The default is 100 Intune licenses to distribute so is perfectly enough for our tests.

Click on “Assign Users” green option.

Set “Show” to list “All Groups”.

On this screen, your sync AD Groups must be listed. Select the one you set for the Intune users and click “Assign” on the bottom page option.

For now, you’ve your (Intune) AD group assigned for Intune licensing. You don’t have to set individual licensing.

Following the question on the previous post, it makes more sense manage groups instead of individual users.

Did you remember the last question post? Check the previous post if you don’t.

On the next post, I’ll share my experience of a mobile device enrollment into my lab.

Enjoy EMS and stay tuned!

/ Fabio

A new challenge is coming… or already came?!..Microsoft Intune!

First of all, my apologies because this is my first non-technical post and I’ve to confess that I’m pretty more comfortable about “passing clicking notes” instead of long speech but as always, I’ll do my best!

Since I’ve started the blog (about one and a half year), I was really focused around deployment technologies – MDT and ConfigMgr and also about the end-user workspace customization due the fact that I really spent much time on investigation (and loved it!). To be honest, was always my main focus since I start my collaboration in Unisys. But, as everyone know, things are moving every day and I was requested to start working for mobile devices management. New concepts, new realities and new needs are coming every time. BYOD, Intune and cloud-based services are across the street and we certainly cannot avoid them.

Just to clarify: I really won’t write long description words about the BYOD (Bring Your Own Device) or cloud-based services. I believe that we can find certainly good information about these terms that were depth by many IT enthusiastic people at several posts.

Second apologies for writing an imperative big cliche: the “mobile generation” isn’t becoming a reality, it is a reality now! (as you noticed on our daily routines).

Mobile devices became a full part of our lives today. I’m not be based on any specific investigation study, but I believe that nowadays, each employee have at least one smartphone that he brings with him daily. In addition, he can probably have a tablet also, not only to check his personal/corporate email, but to do some stuff like reading news, a book, gaming or other types to having fun during break-up times. We’re now talking about a simple scenario around two devices that are present daily. And if we think that all of those devices will probably access to the enterprise network environment, to get for example… internet connection? In addition, will probably access to some network share to copy some file or print some document. Concluding, many tasks can be done with some external device that we don’t know, using our corporate network, and due this fact, “do things” inside of the corporate network. But users/employees can be so more productive with their own devices on corporation. So, why couldn’t we allow these devices to get into our environments? So, how controlled can be those accesses?

Are we sufficiently scared already? Well, here it goes the good news: Microsoft thought (and well!) that this could be a concern for the IT depts and developed some tools to help of its management – based on cloud of course.

Microsoft Intune can be implemented for two distinct ways: cloud only or integrated with SCCM (which is my suggestion and my focus).

System Center Configuration Manager (SCCM) is a very successfully implemented tool for thousands of enterprises to manage thousands of computers and servers around the world. So, Microsoft thinks (well!) of including this cloud-based technology as a feature of SCCM.

MS Intune has several features specially designed for Mobile Device Management (MDM) which is a new concept included on a new point-of-view for cloud-based solutions: EMS (Enterprise Mobility Suite) which includes Azure AD Premium, Microsoft Intune and Azure RMS.

You’ll notice that I’m focused essentially on MS Intune. To see more details about it, follow this link.

Since I started to investigate this theme, I’ve to confess that I found a poor quantity of information regarding Microsoft Intune and less around Configuration Manager integration. Due this fact, I’ll try to cover a lab scenario implementation based on Microsoft Intune integrated with SCCM 2012 R2 SP1 (or SP2 if you want to call it) on the next posts sequence.

As I mentioned above, the next posts can be gold info for some of you that want to build their own Intune with Azure AD Premium lab scenario. I’ll try to split it as much as I can according to share my experience on some tasks:

• Set-up a Lab Environment:
  • How to subscribe a Microsoft Intune trial license with Microsoft Live ID;
  • How to subscribe a Microsoft Azure trial license with Microsoft Live ID;
  • Step-by-step to provide integration between Microsoft Intune and Microsoft Azure subscriptions;
• Azure AD quick notes: Azure AD Connect, Azure AD Premium, UPNs, synchronization service and troubleshooting;
• Set Intune subscription on SCCM 2012 R2 SP1;
• Assign Microsoft Intune licenses to enterprise users automatically;
• Managing Intune Users and Devices with SCCM 2012 R2 SP1 collections;

Stay tuned and enjoy EMS!

/ Fabio