2016-02-05 1 views
0

Je tente de mettre à jour le nom UPN d'un utilisateur Azure AD (chargé avec Azure AD Connect) dans un domaine fédéré via MS Graph en exploitant la bibliothèque .Net ADAL dans Powershell. Je suis raisonnablement certain que j'ai tout configuré correctement dans Azure et dans le PS, parce que si j'envoie une commande de mettre à jour l'attribut UsageLocation, il fonctionne (clippé par souci de concision):Mise à jour AzureAD/O365 UPN via le graphique

$UPN="[email protected]" 
[email protected]{UsageLocation="JP"} | ConvertTo-JSON 
$Result=Invoke-RestMethod -Method PATCH -Uri "https://graph.microsoft.com/v1.0/users/${UPN}" -Headers @{Authorization=$authenticationResult.CreateAuthorizationHeader()} -ContentType "application/json" -Body $Body 
$user=Invoke-RestMethod -Method GET -Uri "https://graph.microsoft.com/v1.0/users/${UPN}?`$select=usageLocation" -Headers @{Authorization=$authenticationResult.CreateAuthorizationHeader()} -ContentType "application/json" 
$user.usageLocation 

JP 

Mais, si je tente de mettre à jour l'UPN à un domaine non fédéré (donc je ne lance pas à l'encontre de la question décrite dans http://blogs.perficient.com/microsoft/2013/03/changing-upn-for-office-365-account-between-two-sso-domains/), je reviens une erreur de serveur interne (500):

$UPN="[email protected]" 
[email protected]{userPrincipalName="[email protected]"} | ConvertTo-JSON 
$Result=Invoke-RestMethod -Method PATCH -Uri "https://graph.microsoft.com/v1.0/users/${UPN}" -Headers @{Authorization=$authenticationResult.CreateAuthorizationHeader()} -ContentType "application/json" -Body $Body 

Invoke-RestMethod : The remote server returned an error: (500) Internal Server Error. 

J'ai essayé beaucoup de variations différentes, y compris récupérer le GUID Azure AD et l'utiliser plutôt que UPN dans la commande PATCH et en utilisant l'ancien Azure AD Graph (qui renvoie le même erreur 500). Je peux faire le changement en utilisant les commandes O365 Powershell:

Set-MsolUserPrincipalName -UserPrincipalName $UPN -NewUserPrincipalName $newUPN 

mais je ne peux pas sembler le faire fonctionner via MS Graph. Les documents pour le graphique impliquent que UPN peut être mis à jour comme d'autres attributs (c.v. http://graph.microsoft.io/en-us/docs/api-reference/v1.0/api/user_update, par exemple). Je me demande si, parce que UPN est une clé, peut-être que cela ne fonctionne pas? Je ne pense pas non plus que ce soit un problème de permission, ceux-ci jettent habituellement "Des privilèges insuffisants pour terminer l'opération". ce qui n'est pas ce que je vois.

Merci!

Update1: Voici tout ce que je peux poisson hors de l'objet d'erreur d'une nouvelle tentative ce matin:

{ 
    "error": { 
    "code": "Service_InternalServerError", 
    "message": "Encountered an internal server error.", 
    "innerError": { 
     "request-id": "cbb08d3c-1143-4d0b-8722-5230b00bd00f", 
     "date": "2016-02-15T16:48:15" 
    } 
    } 
} 
+0

Etes-vous capable d'effectuer une modification UPN entre des domaines non fédérés? Que diriez-vous d'un utilisateur qui n'est pas synchronisé sur place? (Essayer d'exclure le fait que le domaine est fédéré et que l'utilisateur est maîtrisé sur le site.) –

+0

@PhilippeSignoret: Je peux effectuer avec succès un changement UPN pour un utilisateur nouvellement créé avec un domaine non fédéré via MS Graph. L'utilisateur nouvellement créé était uniquement cloud et non synchronisé sur site. Je ne pense pas que je puisse créer un utilisateur UPN non fédéré et synchronisé, car AAD Sync Connect synchronise uniquement les utilisateurs avec des UPN fédérés. J'ai essayé de changer directement d'un domaine fédéré à un autre, mais j'ai reçu Request_BadRequest qui était attendu (plutôt que 500 erreur interne de serveur). –

+0

@ChrisAlexander: Pouvez-vous repro et mettre à jour votre question avec plus d'informations s'il vous plaît? Nous avons besoin du client-request-id et d'un horodatage. Cela nous permettra de suivre le problème plus en profondeur. Je ne suis pas sûr si cette opération est possible, mais même si elle ne devrait pas retourner 500. –

Répondre

0

Je pris un coup d'œil à la trace, et je vais déposer un bug de notre côté pour la Erreur 500 (nous pouvons certainement faire mieux ici). Selon la trace, si vous mettez à jour un utilisateur en le renommant d'un domaine fédéré dans un domaine géré par le cloud, vous DEVEZ fournir/définir un mot de passe dans le cadre de la requête (en utilisant le type complexe passwordProfile). C'est pourquoi la requête échoue en fonction des journaux. S'il vous plaît laissez-nous savoir si cela résout votre problème.

+0

Cela a fait l'affaire! J'ai dû ajuster légèrement mes autorisations d'application Azure pour permettre à cette application de soumettre un mot de passe. Je peux également confirmer que vous n'avez pas à soumettre de mot de passe lorsque vous passez à un domaine fédéré (car mon application change d'utilisateur d'un domaine fédéré à un autre, mais doit d'abord passer temporairement par le domaine géré par le cloud). Edit: Merci !!! –