Tag Archives: spanougakis

#AzureAD Automated Expiration for Office 365 Groups is now in Public Preview

A few days ago, the Azure AD Team announced a new cool feature related to Microsoft Office 365 Groups. As you probably know, Office 365 is based on Azure AD for its identity service. This is the reason why every Office 365 tenant has already an instance of Azure AD up and running.

Office 365 Groups is a great way to collaborate. In case you don’t really know what you can do with Office 365 Groups, here is something that will help you:

https://www.microsoft.com/en-us/dynamics/crm-customer-center/collaborate-with-your-colleagues-using-office-365-groups.aspx and a lot of other articles and blogs that talk about Office 365 Groups, like this video: https://youtu.be/Cg-y3p4E8sA

So while is a great collaboration tool, it can create some confusion after a while, especially if you have created a lot of groups. As a project is completed, the group that you’ve created for that project will be hanging around. So now it’s the time to turn on and use the automatic expiration of groups.

 

How it works

You have to create a new policy in Azure AD, simply select Users and groups, go to Group settings, and select Expiration:

screen1

 

Group owners will receive a renewal notification 30 days before the expiration date of the group, and they can choose to renew it with just a simple click:

screen2

 

If the owner doesn’t renew the group it will be deleted. They will also receive a notification and they’ll have 30 days to restore it back in case they need it:

screen3

 

This is because there is now a soft-delete functionality. Even if you by mistake let a group expire, you still have the option to un-delete it. You will need the Azure AD PowerShell module for this. Simply type:

Get-AzureADMSDeletedGroup

to see a list of all deleted groups. To restore a group you should type:

Restore-AzureADMSDeletedDirectoryObject –Id <objectId>

or if you want to remove it permanently, you should type:

Remove-AzureADMSDeletedDirectoryObject –Id <objectId>

 

How do you know this worked?

To verify that you’ve successfully restored an Office 365 group, run the Get-AzureADGroup –ObjectId <objectId> cmdlet to display information about the group. After the restore request is completed:

  • The group will appear in the Left nav bar on Exchange
  • The plan for the group will appear in Planner
  • Any Sharepoint sites and all of their contents will be available
  • The group can be accessed from any of the Exchange endpoints and other Office 365 workloads that support Office 365 groups.

Thanks for your time!

Have you seen the new #AzureAD Signin Experience? It’s now live!

 

Untitled1

If you tried lately to logon to your Azure or Office 365 portal, you know what I’m talking about. It’s the new way to authenticate, as Microsoft says, the new signin experience.

One of the main reasons behind that change is to unify the signin user interface for Azure AD and Microsoft accounts. But there is something more, called “Pagination”: the new design prompts you to enter your username on the first screen followed by a credential (typically a password) on a second screen. Tests by Microsoft proved that there is a higher success rate for people to sign in.

But now it will be easier to introduce and use more authentication options, like phone signin and certificate-based authentication.

In fact, if you take a look at the screenshot above, you should notice this:

Untitled2 

You guessed it: It’s possible to use the Microsoft Authenticator app, the exact same app we use all this time with MFA in Office 365 and Azure!

So if you try to use the Microsoft Authenticator app, you’re asked to use your phone:

Untitled3

Which, on the other end, if you check your phone, you should see this:

Untitled4

Just tap on “Approve” and you’re in.

 

Microsoft however recommends to check your existing company branding, it should appear as expected using the new layout:

Untitled5 

and remember that since sign-in is now done over two screens, any existing automation might break. This is why today the new UI is optional, you can always switch back to the old one. Microsoft plans switch over to the new UI by default during the last week of September.

Thanks for your time!

Free online courses and e-books available at systemplus.gr

We are really glad to inform you that we recently published some FREE online Microsoft courses and e-books at our course e-shop!

These courses are related to Azure, Windows Server, System Center and give you a great opportunity to start your training at no cost. Just use the word “FREE” as a coupon code during checkout.

It’s a good idea to bookmark the URL of our e-shop, as we are now adding courses and e-books on a daily basis.

Don’t waste your time, start your training now here:
https://systemplus.gr/product-category/free-courses-books/

Do not forget to also take a look at our paid courses that are offered at special prices.

Thanks!

#AzureAD Connect: Version release history

A very important web page to check (and keep it in your bookmarks) and see if you have the latest version of Azure AD Connect:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history#114860

#AzureAD Domain Services admin UX in the new Azure Portal is now in Public Preview

Back in October 2015 and 2016 I’ve written some posts related to the new Azure AD Domain Services feature of Azure Active Directory, which is a brilliant way to provide managed domain services like domain join, group policy, LDAP, and Kerberos/NTLM authentication, all fully compatible with Windows Server Active Directory. You can search and read these articles by clicking on this link here: https://systemplus.gr/?s=azure+ad+domain+services

We’re happy to see that today we have a user interface to manage this great feature just right into the new Azure Portal, so let’s see how it works. As you will see, it’s now possible to create virtual networks, configure group membership of the delegated administrator group, and enable domain services into a simple, intuitive, step-by-step experience.

  1. If Azure AD Domain Services is not enabled for your Azure directory – Create a new managed domain using the new Azure portal, we’ll talk about this in a moment.

  2. If you’ve already enabled Azure AD Domain Services for your Azure directoryContact the Azure AD team via email to migrate your existing managed AD domain to the new Azure portal. From there, you can administer your existing managed AD domain using the new Azure portal.

So what do you need to do in order to enable Azure AD Domain Services?

  1. Go to the Azure portal.
  2. In the left pane, click on New.
  3. In the New blade, type Domain Services into the search bar:

1

Click to select Azure AD Domain Services from the list of search suggestions. On the Azure AD Domain Services blade, click the Create button:

2

Then you should proceed to the next step, which is to specify the DNS domain name for the managed domain. You can also choose the resource group and Azure location to which the managed domain should be deployed:

3

Choose the DNS domain name for your managed domain.

  • The default domain name of the directory (with a .onmicrosoft.com suffix) is specified by default.

  • You can also type in a custom domain name.

Ensure that the DNS domain name you have chosen for the managed domain does not already exist in the virtual network. Specifically, check whether:

  • You already have a domain with the same DNS domain name on the virtual network.

  • The virtual network where you plan to enable the managed domain has a VPN connection with your on-premises network. In this scenario, ensure you don’t have a domain with the same DNS domain name on your on-premises network.

  • You have an existing cloud service with that name on the virtual network.

The next configuration task is to create an Azure virtual network and a dedicated subnet within it. Click Virtual network to select a virtual network.

  1. On the Choose virtual network blade, you see all existing virtual networks. You see only the virtual networks that belong to the resource group and Azure location you have selected on the Basics wizard page.

  2. Choose the virtual network in which Azure AD Domain Services should be enabled. Click Create new, if you prefer to create a new virtual network. It is highly recommended to use a dedicated subnet for Azure AD Domain Services.

4

Click Subnet to pick the dedicated subnet in this virtual network, within which to enable your new managed domain. In the Create subnet blade, specify a name for the subnet, and click OK when you’re done. For example, create a subnet with the name ‘DomainServices’, making it easy for other administrators to understand what is deployed within the subnet.

5

The last step is to create an administrative group in your Azure AD directory. This special administrative group is called AAD DC Administrators. Members of this group are granted administrative permissions on machines that are domain-joined to the managed domain. On domain-joined machines, this group is added to the administrators group. Additionally, members of this group can use Remote Desktop to connect remotely to domain-joined machines. The wizard automatically creates the administrative group in your Azure AD directory. This group is called ‘AAD DC Administrators’. If you have an existing group with this name in your Azure AD directory, the wizard selects this group. You can configure group membership using the Administrator group wizard page:

6

The last step is to actually start the deployment of Azure AD Domain Services:

7

Don’t forget to check the related documentation here.

Thanks for your time!

Join us July 6th for the first Azure AD B2B collaboration AMA!

Join the Azure AD Team on Wednesday, July 6th, at 9am PST/12pm EST for the first Azure AD B2B collaboration-hosted Ask Me Anything (AMA) on the Microsoft Tech Community. You’ll be able to connect directly with the Azure AD B2B collaboration team, who will be on hand to answer your questions and listen to feedback.

Add the AMA to your calendar!

When:

Thursday, July 6, 2017 from 09:00 am to 10:00 am Pacific Time

Where:

The Azure AD B2B Community

What’s an AMA session?

Staff and guys from the Azure AD B2B engineering team will be available to answer any questions you have. You can ask anything about products, services, or even the Azure AD team!

Why they are doing an AMA?

Connect directly with customers, hear your feedback, and answer your questions, such as:

  • What is Microsoft’s strategy around Azure AD B2B?
  • What’s possible with Azure AD B2B today?
  • Will B2B help meet this specific goal I or my customer have?
  • I want to get insight into a specific issue I or my customer is having.
  • How do I submit Azure AD B2B feature requests?

Who will be at the AMA?

Program managers, developers, and technical thought leaders from the Azure AD B2B engineering team in attendance and look forward to connecting with you all!

#AzureAD Connect and the on-premises AD Recycle Bin: What do you need to know about the sourceAnchor attribute

Starting from Windows Server 2008 R2, we had the really good option to enable Active Directory Recycle Bin. After all these years you should be familiar with that option, since we talk often about this topic for that last… 8 years.

If you just want to refresh your memory and learn about the on-premises AD Recycle Bin, you can take a look at this article.

But wait: these days is common to sync our on-premises AD objects to the cloud using AAD Connect, but how this new feature is related to our “local” AD Recycle BIn?

The story here is really simple: If you accidentally deleted an on-premises AD user object and restore it using AD Recycle Bin, Azure AD restores the corresponding Azure AD user object. So lets dig a little bit deeper on this topic and check all the different options that we get:

  • If you accidentally deleted an on-premises AD user object, the corresponding Azure AD user object will be deleted in the next sync cycle. By default, Azure AD keeps the deleted Azure AD user object in soft-deleted state for 30 days.

  • If you have on-premises AD Recycle Bin feature enabled, you can restore the deleted on-premises AD user object without changing its sourceAnchor value. When the recovered on-premises AD user object is synchronized to Azure AD, Azure AD will restore the corresponding soft-deleted Azure AD user object.

  • If you do not have on-premises AD Recycle Bin feature enabled, you may be required to create an AD user object to replace the deleted object. If Azure AD Connect Synchronization Service is configured to use system-generated AD attribute (such as ObjectGuid) for the Source Anchor attribute, the newly created AD user object will not have the same Source Anchor value as the deleted AD user object. When the newly created AD user object is synchronized to Azure AD, Azure AD creates a new Azure AD user object instead of restoring the soft-deleted Azure AD user object. So practically you create a brand new object, without being possible to restore the original AD object: it’s just a new account. Remember: By default, Azure AD keeps deleted Azure AD user objects in soft-deleted state for 30 days before they are permanently deleted. However, administrators can accelerate the deletion of such objects. Once the objects are permanently deleted, they can no longer be recovered, even if on-premises AD Recycle Bin feature is enabled.

sourceAnchor
As we already said above, with AD Recycle Bin you can restore an object without changing its sourceAnchor value. The sourceAnchor attribute is defined as an attribute immutable during the lifetime of an object. It uniquely identifies an object as being the same object on-premises and in Azure AD. The attribute is also called immutableId and you’ll often see that we use both names. So practically this attribute cannot be changed, and for this reason you should have a clear idea on how things work here.

This attribute is used during the following cases:

  • When a new sync engine server is built (a new sync between your on-premises AD and Azure AD), or rebuilt after a disaster recovery scenario, this attribute links existing objects in Azure AD with objects on-premises.
  • If you move from a cloud-only identity to a synchronized identity model, then this attribute allows objects to «hard match» existing objects in Azure AD with on-premises objects.
  • If you use federation, then this attribute together with the userPrincipalName is used in the claim to uniquely identify a user.

It’s really important to select the appropriate attribute, since we said that it cannot be changed:

  • Be less than 60 characters in length
    • Characters not being a-z, A-Z, or 0-9 are encoded and counted as 3 characters
  • Not contain a special character: \ ! # $ % & * + / = ? ^ ` { } | ~ < > ( ) ‘ ; : , [ ] » @ _
  • Must be globally unique
  • Must be either a string, integer, or binary
  • Should not be based on user’s name, sometimes we change the user name!! 
  • Should not be case-sensitive and avoid values that may vary by case
  • Should be assigned when the object is created

Remember: The sourceAnchor attribute is case-sensitive. A value of “chrisSpanougakis” is not the same as “chrisspanougakis”.

If you have a single forest on-premises, then the attribute you should use is objectGUID. This is also the attribute used when you use express settings in Azure AD Connect and also the attribute used by the old DirSync. Generally speaking, there are a lot of cases that is recommended to use the objectGUID attribute, even when we use multiple forests and we do not move users between forests.

Is it possible to change the sourceAnchor attribute?
No. As soon as you create the object and you sync it to Azure AD, it’s not possible to change it anymore. If you want to change it, you should uninstall and reinstall Azure AD Connect. If you install another Azure AD Connect server, then you must select the same sourceAnchor attribute as previously used. If you’ve been using DirSync and move to Azure AD Connect, then you must use objectGUID since that is the attribute used by DirSync. If the value for sourceAnchor is changed after the object has been exported to Azure AD, then Azure AD Connect sync throws an error and does not allow any more changes on that object before the issue has been fixed and the sourceAnchor is changed back in the source directory.

By default, Azure AD Connect (version 1.1.486.0 and older) uses objectGUID as the sourceAnchor attribute. ObjectGUID is system-generated. You cannot specify its value when creating on-premises AD objects. But fortunately, there is a workaround for this: you must use a configurable AD attribute (for example, msDS-ConsistencyGuid) as the sourceAnchor attribute.

You need to use Azure AD Connect (version 1.1.524.0 and after) in order to be able to use the msDS-ConsistencyGuid attribute. For on-premises AD User objects whose msDS-ConsistencyGuid attribute isn’t populated, Azure AD Connect writes its objectGUID value back to the msDS-ConsistencyGuid attribute in on-premises Active Directory. After the msDS-ConsistencyGuid attribute is populated, Azure AD Connect then exports the object to Azure AD.

How we enable the ConsistencyGuid feature?
When installing Azure AD Connect with Express mode, the Azure AD Connect wizard automatically determines the most appropriate AD attribute to use as the sourceAnchor attribute. Since we talk here about a fresh installation of Azure AD Connect, the wizard checks the state of the msDS-ConsistencyGuid attribute in your on-premises Active Directory. If the attribute isn’t configured on any object in the directory, the wizard uses the msDS-ConsistencyGuid as the sourceAnchor attribute.

But: If the attribute is configured on one or more objects in the directory, the wizard concludes the attribute is being used by other applications and is not suitable as sourceAnchor attribute, In this case, the wizard selects to use objectGUID as the sourceAnchor attribute.

Once the sourceAnchor attribute is decided, the wizard stores the information in your Azure AD tenant. The information will be used by future installation of Azure AD Connect. Practicall when the wizard finishes, you should see something like this:

consistencyguid-01

If you do a custom installation of Azure AD Connect, you have the option to select how users will be identified in Azure AD:

consistencyguid-02

Select the first option if you want Azure AD to pick the attribute for you. If you select this option, Azure AD Connect wizard applies the same logic as we described above, during the Express installation of Azure AD Connect. The second option will let you select a specific attribute.

Change the attribute on an a existing installation
If you have an existing Azure AD Connect deployment which is using objectGUID as the Source Anchor attribute, you can switch it to using ConsistencyGuid.

  • Start the Azure AD Connect wizard and click Configure to go to the Tasks screen.

  • Select the Configure Source Anchor task option and click Next.

consistencyguidexistingdeployment01

consistencyguidexistingdeployment02

consistencyguidexistingdeployment03

consistencyguidexistingdeployment04

Thanks for your time!