Getting started with MS Teams guest access

Finally guest access for Teams is RTM as you can read here and here.

I know pretty much every user in Ms Teams has been dying to start using this feature, but before you start inivting your external contacts en masse for all your teams and projects, there are a few things you should know.

  1. Read up on the feature with its capabilities and restrictions! No, really! Do it first! It’s the top sentence in this blog post for a reason.
  2. The guest user must reside in Azure AD, Microsoft account (MSA) is not supported yet
  3. Before you invite, you must at a minimum be a Limited admin in your Azure AD with “Guest inviter” role. Normal users can’t invite guests by default. Also the Team admin must allow you to invite guests.dfsfgeh2rwdf
  4. You need to enable guest access in your tenant
  5. The guest account can’t browse your Azure AD314ewdfsdfsg
  6. In the Teams client you must manually select which tenant you want to access. Teams in other tenants won’t show up side by side with yours.sdf346tgff

 

That’s it, a nice and quick blog post this time. See you in a Team I hope 😉

Advertisements

Automatically assign or revoke Office 365 licenses through AD group membership

Disclaimer: Your use of the script contained in this post is at your sole risk. All information is provided “as -is”, without any warranty, whether express or implied.

Recently a customer asked for a way to automatically assign and revoke licenses in Office 365 based on membership in a group in their local AD. It was a fun challenge so I wanted to share my solution with you. It mainly consist of a Powershell script which runs as a scheduled task, and the script compares the group membership with which users has the corresponding licenses and removes licenses from the users which is not a group member and adds the license if it is a member and doesn’t already have a license. The user account which runs the script must be able to query AD, assign licenses in the tenant and log on as a scheduled task on the server.

First challenge was the non-interactive logon to the tenant, where I also didn’t want the write the password in plain text. Now Powershell can store the password as an encrypted string in a text file and call upon that for logging in. Its encryption key is directly available only for the user which created the string so the password in unavailable for other users. This also means this script has to be run interactively once to create the encrypted password string. Just how secure this solution is, is a matter of discussion but in my opinion it’s better than writing the password in plain text inside the script.

Second part is just to assign the group names to correspond to the license types (SKUs) in the tenant, in this case AzureAD Premium license and O365 E5 license. Then it’s basically a few IF-loops to remove or add licenses to users. Remember the UPN suffix of the onprem-user must match the tenants.

Last thing: This script includes no error handling so if you’re going to put it to use, you should add some sort of error handling with alert (send e-mail, create event in eventlog or similar). Also I’m sure it can be streamlined further but it gets the job done and can easily expand to include several groups with individual license types assigned. Feel free to use this script as a starting point if you want, but at your own risk.


# Get user and UPN from selected group with subgroups
# Assigns location and license in Microsoft cloud
#
# Written by Per-Torben Sørensen
#
# Version: 1.0
#*********************************************************************************************
#
# Change the settings below
#
$sourcegroups = "Cloud_License_AADPremium","Cloud_License_E5" # Name of the groups which controls license assignment
$onlineusername = "cloud_lic_svc@starwarsm16.onmicrosoft.com" # Account which connects to Microsoft cloud and can run this script as a scheduled task
$securefile = "C:\scripts\cloud_lic_svc_securecred.txt" # Encrypted passwordfile for the user.
#*********************************************************************************************
#
# Variables below
#
IF ((test-path $securefile) -eq $false)
{
read-host -assecurestring | convertfrom-securestring | out-file $securefile # Set securestring with password - only need to run interactively once
}
$pass = cat $securefile | convertto-securestring # Building credential
$mycred = new-object -typename System.Management.Automation.PSCredential -argumentlist $onlineusername,$pass # Building credential
#*********************************************************************************************
#
# Logging on to Microsoft Online services
#
Connect-MsolService -Credential $mycred
#
foreach ($sourcegroup in $sourcegroups)
{
$groupname = Get-ADGroup $sourcegroup
$users = Get-ADGroupMember $groupname -Recursive | where {$_.objectClass -like "user"} | Get-ADUser
IF ($groupname.Name -eq "Cloud_License_AADPremium") # Assosiates license to AD group, use Get-MsolAccountSku to find your $sku name
{
$sku = "starwarsm16:AAD_PREMIUM"
}
IF ($groupname.Name -eq "Cloud_License_E5") # Assosiates license to AD group, use Get-MsolAccountSku to find your $sku name
{
$sku = "starwarsm16:ENTERPRISEPREMIUM"
}
#
# Check membership and removes license for non-members
#
$msolusers = Get-MsolUser | ? {$_.Licenses.accountskuid -like $sku}
foreach ($msoluser in $msolusers)
{
IF ($msoluser.LastDirSyncTime -ne $null) # Checks if the user is cloud-only, if so skip to next user
{
$check = Get-ADUser -Filter * -Properties * | ? {$_.userprincipalname -eq $msoluser.UserPrincipalName}
if ($check.memberof -notcontains $groupname) # Check groupmembership and remove license if the user is not a member
{
Set-MsolUserLicense -UserPrincipalName $msoluser.UserPrincipalName -RemoveLicenses $sku
}
}
}
#
# Check group membership and assign location and license
#
foreach ($user in $users)
{
$msoluser = Get-MsolUser -UserPrincipalName $user.UserPrincipalName
IF ($msoluser -ne $null)
{
IF ($msoluser.UsageLocation -ne "NO" ) # Check and set locaion "NO" (Norway)
{
Set-MSOLUser -UserPrincipalName $msoluser.UserPrincipalName -UsageLocation NO
}
IF ($msoluser.Licenses.accountskuid -notcontains $sku) # Check and assign license
{
Set-MsolUserLicense -UserPrincipalName $msoluser.UserPrincipalName -AddLicenses $sku
}
}
}
}

What is Azure Domain Services?

Azure Active Directory (AAD) is, as I’m sure you know, the identity services in Microsoft Azure. Unlike Windows Active Directory (WAD) which has been with us since Windows 2000, AAD doesn’t use Kerberos for authentication since Kerberos isn’t suited for internet traffic and slow/unreliable WAN connection. Obviously the major drawback is that AAD can’t communicate directly with most of our current applications and systems.

To combat this drawback, Microsoft has released Azure Domain Services (currently in preview) which is a feature that allows one AAD to communicate with Kerberos over one virtual network. This is NOT a full version of WAD, it is only AAD made Kerberos-enabled which gives you access to a some of the features from WAD, most of them are read-only however.

This is essentially “domain controller-as-a-service”, so there is no FSMO roles, AD sites, Global Catalog, schema extentions and such to configure or troubleshoot. After deployment you get 2 IP addresses to use as primary and secondary DNS server, which in turn lets you communicate with AAD using Kerberos. This includes joining the domain with you servers and clients. This feature is not to be confused with Windows 10 Azure device join which it something entirely different.

Also I want to remind you that this feature is in preview so things are likely to change from what you can read here.

Implementing Azure Domain Services

Implementing Azure Domain Services is very easy.

  1. Create a group named “AAD DC Administrators” and join the user accounts you want as your admin account to this group. The members won’t be Domain Admins as we are used to from WAD, but this is as close as you get.ads0b
  2. In the Azure portal, find you AAD and under configure you’ll find this setting to enable Azure Domain Servicesads01
  3. When enabled you have to select your domain DNS name and which virtual network this AAD will provide Kerberos over. If this network has a site 2 site VPN, your AAD will be available to resources on-premises.ads2
  4. Notice this message, which says you need password synchronization in order to log on AAD using Kerberos. This also means that Federation is not supported. The procedure is different for cloud accounts and on-prem accounts, but the link in the message describes very well what you need to do, so I’ll just link it here.ads3
  5. Now you have to wait..a lot. Enabling this takes a long time, about 20-30 minutes. Eventually you’ll get the 2 IP addresses you need to use to reach your domain. You should add both as DNS servers in your virtual network in Azure. It will take some time before the vm’s in Azure are updated so you can either refresh the IP’s or give the servers a reboot.ads5
  6. I have a cloud-only user to function as my admin account, so before I can join my servers to the AAD, I have to reset its password to generate the hash (step 4) so I do so at http://myapps.microsoft.com where you find the change password option. (“Endre passord”, sorry this screenshot is in norwegian)ads9
  7. And finally my server has the correct DNS servers and it can join AAD as if it was an ordinary WAD. ads6

ads7

ads8

 

 

 

 

 

 

 

Taking a closer look at an AAD-joined server

After my server joined my AAD and rebooted it’s available for my AzureAdmin account. So let’s take a closer look on how this works. Starting at the local administrator group on my member server where you see the group we added in step 1 thereby giving me access to the server.

ads_localadmingroup

 

 

 

 

 

 

 

 

 

 

So naturally I install the RSAT for AD and Group Policy and start to play around.

First of all having a look at FSMO roles:

ads_fsmo

 

AD sites and services won’t show anything but an error, so nothing to see there.

AD domain and trust just shows us the usual information with no ability to change anything at all.

AD users and computers on the other hand is a little more interesting. Here we see the AAD OU structure and we have our users and groups from the Azure portal in “AADDC Users” and our newly joined member server in “AADDC Computers”. This view seem to be completely read-only and nothing can be changed or edited. Note there is no “Domain Controller” container.ads_aduc1

 

 

 

 

 

 

 

Turns out I can create a new OU on the domain level and in here I can create new groups and users which I can edit. As of now this seem to have no function at all as I can’t authenticate with this new user account and it doesn’t show up in the Azure portal.

ads_aduc2

Group Policy is even more interesting.
ads_gpmc1

 

 

 

 

 

 

 

 

There are 4 GPO’s present Default domain and domain controller policy, plus AADDC Computers and AADDS Users (both linked to the OU with the corresponding name).  Those last 2 GPO’s can be edited so you are able to deploy some GPO settings to your domain joined computers and users. You can also change GPO links, enforce, block inheritance and change GPO Staus (disable all users or/and computer settings) However you can’t do any of the following:

  • Create new GPO or delete existing ones
  • Change GPO security filtering
  • Create WMI filters
  • GPO links

ads_gpmc2

 

 

 

 

 

 

 

 

 

 

DNS: Your account will not have any DNS server rights so trying to connect a DNS console againt the DC will only throw an access denied error.

Add domain controllers: No, you can’t promote an azure vm as an additional Domain Controller 😉

Conclusion

I think Azure Domain Services is a curious thing, while being far from a replacement for you WAD, it does provide the ability to join servers and clients to an AAD and communicate with each other using Kerberos. You can of course use it as if it was a normal WAD, but the management of both users and computer are very limited. Communication using Kerberos is the whole point of this feature and it should open up some new possibilities in both hybrid environments and perhaps also during migration from on-premises to cloud. Another possible application for this feature could be in combination with Azure Remote App.

Again this feature is in preview so I’m sure the re will be changes coming, probably based quite a bit on user feedback.

Enable immediate replication between AD sites

What is immediate replication?

Active Directory has 3 replication models:

  1. Within a site (Intrasite) the domain controllers use Change Notification to alert adjacent dc’s of changes made in AD. By default, after 15 seconds the first replication partner is notified and 3 more seconds to each subsequent replication partner.
  2. Between sites (Intersite) Change Notification is not used. Replication only happens on a schedule with every 15 minutes as the shortest configurable interval.
  3. Account lockout, changes to password policy, DC password changes and a few other situations trigger urgent replication which happens as quickly as the domain controllers are able and bypasses all other replication interval.

The intersite replication can however be configured to use Change Notification and this will bypass the replication schedule of the site link and replication will occur as if the domain controllers were in the same site. This does of course increase the traffic of you WAN link so make sure you have the bandwidth and latency to handle it.

How to enable immediate replication

The procedure is slightly different for automatically and manually changed sitelinks

For automatically created sitelinks:

  1. Open ADSIEDIT
  2. Connect to Configuration Naming Context
  3. Expand Sites –> Intersite Transport –> IP
  4. Right-click the relevant sitelink and select properties
  5. Change the value of “options” to 1

wp_intersite_repl1

For manually created sitelinks:

  1. Open ADSIEDIT
  2. Connect to Configuration Naming Context
  3. Expand Sites –> (The site name) –> Servers –> (Servername) –> NTDS Settings
  4. Right-click the relevant sitelink and select properties
  5. Change the value of “options” to 8
  6. Repeat for every manually configured sitelink (if desired)

wp_intersite_repl2

That’s all there is to it. Changes in AD will now flow as if the domain controllers are within the same site.

Active Directory disaster recovery with Windows Server Backup

Hello.

Earlier I wrote a post on how to backup and restore objects in Active Directory with Windows Server Backup here:  https://pertorben.wordpress.com/2013/04/15/active-directory-backup-and-restore/

Here I used the command wbadmin start systemstatebackup -backuptarget:(path) to perform a system state backup on a domain controller and use Directory Service Restore Mode (DSRM) to recover deleted items, as was explained on Microsoft Technet. However there is one drawback to this method, and it’s that you can’t perform a disaster recovery of your AD using this backup, and by disaster recovery I mean that all of your servers are completely gone and you have nothing left except your backups. If you try to use a complete server restore with this backup, this is as far as you will get.

Disaster Recovery error

So in order to do a disaster recovery you need a backup that support this. With wbadmin you can run

wbadmin start backup -allcritical -systemstate -vssfull -backuptarget:(path):

With this backup you can boot a blank server form the 2012 R2 install media and select Repair your computer. Choose image restore and it should detect your backup if it’s available.

DR_AD_OK

After the restore you have a complete server restored form the point in time of which the backup was taken. From here you can seize any FSMO roles if you need, then and start promoting more domain controllers. In a disaster recovery scenario I would rather promote new domain controllers instead of running restore on every single Domain Controller. Note that your NIC will most likely be set to default on the restored server so you may need to set the correct IP address again.

So the big question now is: Can you use this backup procedure to do a restore of a deleted object in AD, instead of a complete Disaster recovery? The answer is yes. You don’t need to have 2 backups (one of AD and one for disaster recovery). All you need is the backup from this post and follow the procedure form the post I linked at the top to restore deleted object in AD.

Active Directory backup and restore

UPDATE: I’ve written a related post about disaster recovery of Active Directory, I strongly recommend that you all read it. https://pertorben.wordpress.com/2015/02/21/active-directory-disaster-recovery-with-windows-server-backup/

Active Directory is one of the most central service in your infrastructure I wanted to write a quick post on how you can perform a backup and a restore, and this post will cover the basics of it. As with all other restore scenarios I think it’s very important to practice the restore procedure before you really need to restore something.

Authorative vs non-autorative restore

When you restore an object in AD then the object will we updated in the next replication run, this is because the other domain controllers have a newer version of the same object. This also means that if you restore a deleted user then the user is deleted again when replication runs. This is because a regular restore is a “non-authorative restore”. If you perform an “authorative restore” then the restores user will remain and update the other domain controllers.

Backup Active Directory

You can use Windows Server Backup to backup Active Directory quickly and easily. Note that the backup destination can’t be a local systemdrive on the domain controller. To backup AD using Windows Server Backup simply run

wbadmin start systemstatebackup -backuptarget:(path)

Directory Services Restore Mode

Every time you want to perform a restore you must boot you DC into “Directory Services Restore Mode” (DSRM). I know AD now is a service which you can stop and start, but there may be information stored in memory or other caches. Don’t cut cornes here, boot into DSRM. You need the DSRM password on your domain controller and if you find at this point that you don’t know this password or haven’t documentated it, then I strongly suggest you look into your disaster recovery plans because this is vital for disaster recovery. The DSRM password can be reset using “ntdsutil”. I recommend that you enable DSRM as the default boot option so you don’t have to struggle with F8-spamming when the server boots. You can run this command to enable boot into DSRM every time the server boots:

bcdedit /set safeboot dsrepair

Now that the server boots into DSRM every time you can safely reboot the domain controllers without fear of booting into normal mode prematurely. When you’re all done with the restore procedure and want to boot normally you can run

bcdedit /deletevalue safeboot

Also note that the shutdown.exe has a new switch: -o which lets you choose how to boot your server, though this is only the next boot and Windows Server 2012 wants an additional reboot into DSRM for doing an authorative restore. Therefore I prefer the bcdedit approach.

Performing a restore 

Before you perform an authorative restore it helps to note the Distinguished Name of the container where it resided. Then you can reboot your DC into DSRM and login using the lodal administrator account and DSRM password. Then you just use wbadmin to restore AD

wbadmin start systemstaterecovery -version:(versionnumber)

To find your backupversion use the command

wbadmin get versions

In this screenshot I’m performing a restore from backup on one of my lab DC’s using wbadmin. I’ve deleted a user named “user 1” who was a member of the group dnsadmins.

ad-restore1

After the restore the server wants a new reboot, if you want to do an authorative restore then you have to boot straight into DSRM again to avoid having the object deleted by replication. This is why the bcdedit approach is very useful in my opinion.

ad-restore2

After the reboot you login again with the DSRM password and you should see a popup confirming the restore has successfully completed.

Making the restore authorative

Now it’s time to run ntdsutil from a command prompt. There you must first activate the ntds instance and then then the authorative restore prompt. Here you can either restore an OU using

Restore subtree (DN of the container)

or a simple objece with

Restore object (DN of the object)

Below I make an authorative restore of the “user 1” object I have deleted earlier.

ad-restore3

Now the next part is to fix the group memberships if the restored user is member of groups in other domains. The output in the screenshot above name a .ldf file which you can use to fix this. You don’t have to do this to restore group memberships within the same domain. Just exit ntdsutil and from the command prompt you run

ldifde -i -k -f filename.ldf

Now you can remove the boot-option for booting into DSRM and reboot your domain controller normally. The replication will make the user restored on all domain controllers with group membership intact.