-
Notifications
You must be signed in to change notification settings - Fork 102
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Import-D365AadUser with AD lookup is using invalid email as network alias #856
Comments
Hi @gertvdh , thanks for the suggestion. If I understand correctly, this would work similar to the existing parameters IdValue or NameValue. Let's call it
With the new behavior, It would use
For anyone else like me wondering where this then eventually ends up in the network alias (which is displayed as Email in the D365FO user interface): The second parameter of
Would this work for you? |
Yes, you are correct. Do you want me to foresee a pull request for this? |
That would be great if you could do that, yes! |
Did you get time to look at this? I'm doing a major refactor of this specific cmdlet - as we want to move away from the AzureAD module dependency. Let me know, if I should incorporate your needed changes - while doing the refactor 👍 |
I was planning on doing the work this week or early next next |
Please do - then I'll do the initial implementation for the rest calls, and then we can work together to merge your needs into my PR afterwards |
Could any of you test this?
Note the v2 suffix. You will need to copy&paste the original cmdlet with above code. |
I pushed that version into https://github.com/d365collaborative/d365fo.tools/tree/test-import-d365aaduserv2 to make it easier for testing and further discussion. Also created a little test script Test-ImportD365AadUserV2.ps1 in https://gist.github.com/FH-Inway/ba12906c35df73cded460649cf742d54 Unfortunately, I could not get past the authentication. I have a user with sufficient rights and no MFA. Without With Unfortunately, I do not have any other users I can test this with. What would work is authentication with the certificate from Secure one-box development environments - External integrations. See the second script Connect-AzAccountWithCertificate.ps1 in https://gist.github.com/FH-Inway/ba12906c35df73cded460649cf742d54 |
Did - you in any way, have the PowerShell sessions running in elevated mode (Run As Admin)? Please try a non-admin session. The best test, is to get the ordinary Login-AzAccount to work - before utilizing the cmdlet. Then we can separate what issues you are facing. |
I tried PowerShell in non-admin session, but no luck at first, got the same behavior as before. I then tried what the message suggests, running Login-AzAccount with the -TenantId parameter. This worked! It also works with a provided credentials object. So I added a -TenantId parameter to the new version of Import-D365AadUser: 9e4ae83 |
How do we move from here? |
I created pull request #860 with @gertvdh, your and my changes. @gertvdh Hope you don't mind me creating a new pull request. It made it easier to add @Splaxi 's and my changes and also target the master branch (we recently switched from development to master as the default branch). Also added you as an author to the cmdlet. |
This is now available in version 0.7.18 🎉 |
When importing users, the email address is looked up on Entra and then used as network alias for the user.
In our case Entra is giving a full email address ([email protected]) and not the Entra id ([email protected]).
Can we foresee an override option to use the UserPrincipalName as email?
The text was updated successfully, but these errors were encountered: