I am looking to automate adding a user to an Azure AD group when he/she enrolls into MFA using the http://aka.ms/mfasetup wizard.
When: User enrolls into MFA
Action: Add user to Azure AD Security Group "0000_People_with_MFA"
I looked at Microsoft Power Automate but there does not appear to be any triggers from Azure AD. I can perhaps use a webhook or something to call a PowerShell script running on Azure Functions, but there needs to be some way of capturing this event.
Alternatively I can run something from Azure Functions to query AAD every 10 or 15 minutes to add users, but I do not know how to go about that approach either. In pseudo-code it would look something like this:
for (let user of query("SELECT userPrincipalName FROM users WHERE mfaEnabled = 1"))
addToAADGroup("0000_People_with_MFA", user)
Any ideas on how this can be accomplished?
You can use these PowerShell cmdlets to get list of users with MFA Enabled:
Install-Module MSOnline If the module is not installed already.
Connect-MsolService Login with Global Admin account.
Get-MsolUser -All | select DisplayName,BlockCredential,UserPrincipalName,#{N="MFA Status"; E={ if( $_.StrongAuthenticationRequirements.State -ne $null){ $_.StrongAuthenticationRequirements.State} else { "Disabled"}}} To get a list of users with MFA Enabled
Then you can use Add-AzureADGroupMember to add the users to the group. You can also add the users to a CSV file and bulk add them to a group. (See also.)
I would also recommend checking out the Graph API, where you can query a list of user registration details. https://learn.microsoft.com/en-us/graph/api/resources/credentialuserregistrationdetails?view=graph-rest-beta
Related
We have an application which uses Azure B2C and Azure Active Directory.
Problem: User A wants to set his specific email address. But this is not possible because User B already used this email address before. User B has a proxyaddresses entry for this email, although User B does not use the emailadress anymore.
We tried to remove the smtp entry in proxaddresses for User B:
Azure Portal --> Values for ProxyAddresses are not editable
Windows Powershell
Connect-AzureAD -TenantId <TenantID>
$User = Get-AzureADUser -ObjectId "<ObjectIDUserB>"
$User.ProxyAddresses //Displays all proxyaddresses(smtpEntries)
$User.ProxyAddresses.Remove("<smtpEntry>")
Set-AzureADUser -ObjectId "<ObjectIDUserB>" //But then there is no parameter for ProxyAddresses to update
Are we missing something here or is there another way to remove a proxyadress entry for a user in azure ad?
Not sure if AAD Powershell can make it. But there is a quick way to do this.
You can log into O365 admin center with an admin account.
Find the User B and click on it. After the user details open, click on Manage username and email.
Then you can click on "···" -> Delete alias to remove the smtp proxaddress.
ProxyAddresses attribute for a unlicensed cloud-only user is read only unfortunately. There is a hacky workaround that will remove unwanted proxyAddresses for a cloud only unlicensed user though. Those steps are:
Soft-delete the user with the bad proxyAddress. Example: user#domain.com
Create a dummy user dummy#tenant.onmicrosoft.com and update this dummy user's mail attribute with the SAME email that you want to remove from the user soft-deleted in step 1.
Using the MSOnline powershell module run the following cmds:
Connect-MsolService
Restore-MsolUser -UserPrincipalName user#domain.com -AutoReconcileProxyConflicts
Confirm from Azure AD portal that the proxyAddress proxyaddresstoremove#domain.com has now been removed from user#domain.com account. From Azure AD portal, you may now delete dummy#tenant.onmicrosoft.com.
NOTE: This process is ONLY needed for a unlicensed cloud-only user. If user is a M365 liensed user you can use the M365 admin portal to remove the alias mentioned in another answer. If the user is a synchronized user from on-prem AD, then on-prem AD is the source of authority and you can update proxyAddress there and sync to AAD.
There is a very simple answer, I fought this for hours today. Simply run a powershell script to add the "smtp" address back to the account that you are showing it was on, then run a powershell to remove it. We had never AD Synced this account... only thing I can think of is when it was removed a while back from Exchange, it got hung up in Azure.
Add:
Set-Mailbox account#domain.com -EmailAddresses #{add="smtpaddress#domain.com"}
then Remove:
Set-Mailbox Account#domain.com -Emailaddresses #{remove="smtpaddress#domain.com"}
I'm trying to run (Get-AzContext).Account.id in a powershell runbook (through the azure portal), to get the email of the currently connected user.
The issue is that the value returned seems to be hidden for some reason.
Here's an example of the kind of output I'm receiving "d3f47515-0254-43tv-8060-c824e201088h"
No, it is not been hidden. I suppose you Connect-AzAccount with the service principal in the runbook, not the user account. The d3f47515-0254-43tv-8060-c824e201088h is the Application ID of the service principal.
To confirm this, just run (Get-AzContext).Account.Type, it will return ServicePrincipal.
If you logged in with a user account, it will return the Userprincipal name(i.e. email you want, note, strictly speaking it is different from email, but from your description, it should be the one you want)
Can someone please help me with the following, thanks in advance
I setup AD Connect in a LAB and my LAB Active Directory users are syncing OK to my LAB Azure AD
I then went through the Azure AD Connect setup wizard a second time to sync 'custom sync options' and chose 'Directory Extension Attribute Sync' and chose to sync two additional attributes (for testing), I chose the Active Directory attributes 'adminCount' and 'carLicense' I have a domain admin user called Craig who has his adminCount attribute set to 1 and I added a value for carLicense
When I check Get-ADSyncGlobalSettings
I can see under Microsoft.OptionalFeature.DirectoryExtensionAttributes the carLicense and adminCount listed (among other attributes) therefore looks like AD Connect should sync these two attributes from AD to Azure AD right?
However even after restarting AD Connect and doing a delta sync too I still do not see these attributes on my Azure AD User when I do Get-AzureADUser -SearchString Graig | select -ExpandProperty extensionproperty
There is no sign of the adminCount or carLicense attributes or their values in the output
Please advise, where I am going wrong?
Do I need an Azure AD P2 license or something to sync additional built in active directory attributes?
I also set up a separate custom rule to sync an AD attribute to extension13 of the AAD user class.
The above appears in the Metaverse under AD Connect OK (with the correct values populated)
However, there are not appears in the AAD User object, as above any idea please
Thanks in advance
CXMelga
I also set up a separate custom rule to sync an AD attribute to extension13 of the AAD user class.
If you sync the extension attribute to the extensionAttribute13, you are unable to get that via Azure AD powershell Get-AzureADUser.
The extensionAttribute13 belongs to onPremisesExtensionAttributes which is a property just for the User object in Microsoft Graph, but the AzureAD powershell calls Azure AD Graph API, the onPremisesExtensionAttributes property is not a property of the User in AAD Graph.
So if you want to get the attribute, here are two solutions for you to refer.
1.Use the Microsoft Graph - Get a user to do that, use the query as below in the Microsoft Graph Explorer. Or if you want to use powershell to do that, your option is to call the MS Graph in powershell with Invoke-RestMethod, a sample here.
GET https://graph.microsoft.com/v1.0/users/<object-id of the user>?$select=onPremisesExtensionAttributes
2.When you use the Azure AD Connect to sync, edit outbound synchronization rule like below. In your case, it should be like extension_3e2cd06ca3494546888b069a891b4bb6_adminCount. See this link for more details.
Then you will be able to get the extension attribute with the command as below(I recommend you not to use -SearchString parameter, sometimes it returns nothing.)
Get-AzureADUserExtension -ObjectId <object-id of the user>
Or
Get-AzureADUser -ObjectId <object-id of the user> | select -ExpandProperty extensionproperty
I am working on Using Single Sign on for my Salesforce sandbox. I am using Azure AD as the authentication provider. I was able to add a few users in Azure AD and actually got the Single sign on working for my SF sandbox (for those users). The problem is my sandbox has 500 users and I would like to add them all to my Azure AD. Here is the document I followed to get the single sign on working for my test users. So my next step/question is how do I bulk uloa all my user information in Azure AD so that all of them can have single sign on to my SF sandbox?
Thank you
Once you have all user information available in a CSV file, you can make use of PowerShell and Import-csv to import all userinformation.
Then use New-AzureADUser command to create these users. Skeleton like this..
foreach($user in import-csv "E:\userinfo.csv")
{
Write-Host "Processing item with.. UserName="$user.DisplayName
# Make use of variables like $user.DisplayName and so on in your commands here..
# New-AzureADUser -DisplayName $user.DisplayName ... and so on..
}
A very detailed script with similar strategy is availble here: Creating Bulk users in Azure AD with PowerShell
A customer made me a co-administrator of his Azure subscription. However, I am unable to edit his Active Directory, ie add/edit users, create applications, etc.
Why can't I access that? I'm thinking perhaps the Subscription is owned by the AD and not the other way around.
What do each of the role levels in AD allow? There's
Global Admin
Billing Admin
Service Admin
User Admin
Password Admin
I believe the primary reason for this error is because when a co-admin with Microsoft account is added to a subscription, it gets added into the subscription AD as Guest user type. In order for you to get access to that AD so that you can perform the operations on the AD, you user type needs to be changed to Member from Guest. I had exact same issue with one of the users of our product and the steps described below solved the problem.
To change the user type, one would need to use AD PowerShell Cmdlets. The process is rather convoluted and needs to be done by your customer.
First, check with your customer if they themselves are using Microsoft Account for signing in into the portal. If they are, then they would need to create a user in their Azure AD. Please see this thread for why this is needed: PowerShell - Connecting to Azure Active Directory using Microsoft Account.
Next, they would need to sign in using this user account because one would need to change user password on the 1st login.
Install AD Modules. You may find these links useful for that purpose: https://msdn.microsoft.com/en-us/library/azure/jj151815.aspx#bkmk_installmodule, http://www.microsoft.com/en-us/download/details.aspx?id=41950 (Please choose 64 bit version) and http://go.microsoft.com/fwlink/p/?linkid=236297.
Launch PowerShell and execute the following commands:
.
$cred = Get-Credential #In the window that shows up, please specify the local AD user credentials.
connect-msolservice -Credential $cred
(Get-MsolUser -SearchString "your microsoft account email address").UserType #This should output "Guest". If it doesn’t, please stop and do not proceed further as there might be some other issue.
(Get-MsolUser -SearchString "your microsoft account email address") | Set-MsolUser -UserType Member
(Get-MsolUser -SearchString "your microsoft account email address").UserType #This should now output "Member"
If somehow the problem still persists, ask your customer to login into the portal, delete your user record from AD users list and add it again. That should also take care of this problem.
The answer was that I needed to be set up as a Global Administrator in the Azure AD domain.
Both answers above seem to be correct in it's own way.
As a starter subscription administrator does not automatically make you an Azure AD administrator. You'd need explicit role grant on the target Azure AD.
Second aspect is the type of the account used. If it's in current Azure AD or Microsoft Live account all is well.
In case that account is part of an external Azure AD, by default user type is "Guest"(can login, but cannot control event if assigned "Global admin"). Therefore PowerShell commands highlighted above should be executed to change user type to "Member".
Some more helpful info can be found here (it is mentioned as a Visual Studio Team Services issue, but actually applies to most Azure related services).