J'essaye d'automatiser un script PowerShell qui rassemble les données d'O365. J'ai une configuration utilisateur limitée spéciale avec les privilèges requis sur O365 et également avec une connexion locale autorisée sur le serveur afin que je puisse "exécuter en tant que" cet utilisateur (ce que je fais pour tous les scripts ci-dessous. J'ai vérifié différent, erreurs attendues lors de l'exécution en tant qu'autres utilisateurs).
Le script fonctionne correctement de manière interactive lorsque les informations d'identification sont définies comme ceci et que la session est ouverte:
$cred = Import-Clixml -Path C:\batch\${env:USERNAME}_cred.xml
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
Cependant, si je crée les informations d'identification fichier pour l'automatisation avec:
Get-Credential | Export-Clixml -Path C:\batch\${env:USERNAME}_cred.xml
Et puis l'accès depuis le script via:
$cred = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -Authentication Basic –AllowRedirection
Le chargement du fichier d'identification semble réussir . J'obtiens alors "Accès refusé" sur la session ouverte, et puis bien sûr le reste du script échoue en raison de la session étant nulle. Je coupe et colle le mot de passe dans tous les cas (en plus, j'ai essayé de nombreuses fois, y compris la saisie manuelle), donc je ne pense pas que ce soit un simple problème de faute de frappe. Cela ressemble plus à quelque chose que je ne comprends pas fondamentalement à propos de PowerShell. En fin de compte, j'aimerais non seulement que les informations d'identification soient automatisées, mais aussi qu'elles soient exécutées à partir du planificateur de tâches s'il y a des paramètres spéciaux au-delà de ceux dont j'ai également besoin.
3 Réponses :
Je ne vois rien de mal de votre code du point de vue de PowerShell. J'ai testé la façon dont vous créez des informations d'identification dans un domaine d'entreprise et j'ai pu créer une nouvelle session en important le fichier d'informations d'identification XML qui a été créé en exportant les informations d'identification comme vous l'avez fait. Je suppose alors que cela pourrait être lié à MS Exchange .
Je peux vous suggérer des alternatives à essayer:
$username = "yourusername" $password = Get-Content C:\mypass.txt | ConvertTo-SecureString $cred = New-Object System.Management.Automation.PsCredential($username, $password) $session = New-PSSession -Credential $cred .....
C'était la version chiffrée de votre mot de passe est enregistré sous forme de texte.
Dans votre script d'automatisation, vous pouvez maintenant faire ceci:
# First we need to get the encrypted password: $TempCred = Get-Credential # provide credentials to the prompt # now the encryption to be saved in a file $TempCred.Password | ConvertFrom-SecureString | Set-Content C:\mypass.txt
Je ne suis pas sûr que cela fonctionne dans votre cas , cela a fonctionné dans le domaine de mon entreprise. Encore une fois, cela a fonctionné pour moi la version XML aussi. Je propose simplement des alternatives à essayer si vous ne souhaitez pas savoir pourquoi la méthode XML n'a pas fonctionné.
Nous l'avons fait fonctionner, mais je ne me souviens pas comment. J'avais l'intention d'essayer de reproduire la séquence de la solution et de poster ici, mais je n'ai pas encore eu le temps.
Je suis heureux que cela ait fonctionné, mais je suis également désireux de connaître votre solution.
@BrianKnoblauch ~ Vous rappelez-vous comment vous l'avez fait fonctionner?
@InteXX Eh bien, l'un de mes utilisateurs vient de mentionner il y a quelques semaines qu'il n'avait vu aucun des rapports à ce sujet depuis quelques mois ... Je suis allé vérifier, et bien sûr, cela ne fonctionne plus. A fait une réinitialisation rapide des informations d'identification au cas où ce serait tout, mais aucun changement. Malheureusement, avec mes autres pauses / correctifs et la charge de projet, je n'ai pas encore eu le temps de travailler sérieusement là-dessus.
@BrianKnoblauch ~ Eh bien, ce n'est pas une coïncidence! J'espère que vous pourrez le faire fonctionner.
J'ai pu faire fonctionner cela, au moins dans mon environnement, en incluant un appel à Import-PSSession:
$Credential = Import-Clixml -Path D:\Modules\O365Credentials.xml $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credential -Authentication Basic -AllowRedirection Import-PSSession $Session -DisableNameChecking Get-Mailbox
La MFA est-elle activée sur le compte en question? Si tel est le cas, vous pouvez essayer ceci .
Ce script:
Vous pouvez également effectuer ces opérations manuellement. Plus d'informations, y compris une présentation détaillée, sont disponibles ici:
https://o365reports.com/2019/ 04/17 / connect-exchange-online-using-mfa /
Si vous importez le fichier dans une session interactive et vérifiez le mot de passe enregistré (utilisez la méthode GetNetworkCredential sur l'objet pscredential) le mot de passe est-il le même? Je ne sais pas si vous pouvez simplement exporter une chaîne de sécurité avec export-clixml.
Utilisez-vous différents hôtes ou utilisateurs lorsque vous essayez d'importer / d'exporter le fichier? Le mot de passe est chiffré par DPAPI et est unique à une combinaison utilisateur et hôte .
@bluuf Si j'écris-Host le $ cred.Username, il est correct. Write-Host sur $ cred.GetNetworkCredential (). Le mot de passe ne renvoie pas le mot de passe. En fait, je reçois une section de code d'un script PowerShell entièrement différent dans le même répertoire!
@ TheIncorrigible1 Même hôte, même utilisateur.
Si tel est le cas, il manque quelque chose à votre question car je ne suis pas en mesure de reproduire votre problème.
@ TheIncorrigible1 Je peux reproduire localement ici avec juste les extraits de code ci-dessus, il n'y a rien d'autre requis du script complet.
Quelle version de PowerShell et OS?
@ TheIncorrigible1 Centre de données Windows Server 2012R2 x64 avec Powershell 5.1 B14409 R1018