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)
Related
I need to add external users to my subscription. Each user would get access to only one resource group, which is created for him.
From the portal, I can do it manually and it would recognize that the user is new and would get an email.
However, New-AzRoleAssignment gives me an error, saying that The provided information does not map to an AD object id.
Does Powershell allow to 'force' invite a user or I need to New-AzureADMSInvitation first?
You need to invite the user to the AAD tenant first via the portal or New-AzureADMSInvitation as you mentioned first, New-AzRoleAssignment will not do that for you.
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 am almost new to Azure. My client had created an Azure account and sent invitation to me. I had accepted her invitation to join her Azure portal. However when I log in with my username, it shows me "No subscription". My client is saying she has given me every access rights, but I am not able to do anything there. Even I am not sure if I have really joined her Azure portal.
Here is the image if when I tried to access Free Services.
For what i understand is that the current directory you are working in doesn't have the rights that you are expecting. And your client has added you to another subscription with all the required rights. All you need to do is switch your directory to the one which has the subscription provided by your client.
Just Click on your profile avatar(or name) on the top right of the portal.
Select the option Switch Directory form the pop-up.
And choose your concerned directory + Subscription.
I'm trying to change the user principal name on my Azure AD user using a PowerShell command Set-MsolUserPrincipalName that I found in the Microsoft documentation here. This works fine and changes the user principal name, but it also changes the email property to the same value as well.
Example command:
Set-MsolUserPrincipalName -UserPrincipalName "davidc#contoso.com" -NewUserPrincipalName "davidchew#contoso.com"
Is there another way to change the user principal name without affecting the email of the user?
There is no way to change the user principal name without affecting the email of the user. The mail property is read-only, and the principal name should map to the user's email name.
It is now possible to change the user principal name in Azure AD without changing the email for the user and without changing the on-premises user principal name. It appears they are both managed separately now. At the time of my writing this, you can pull up the user in Azure AD and Edit the properties and go to the Identity tab where you will see user principal name and under the On-premises tab there is a separate non-editable user principal name which remains unaffected when making changes to the other.
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).