Migrer l'activation silencieuse d'Office 365 basée sur les clés de registre vers une nouvelle configuration

A. Créer et tester un sous-domaine Kerberos

1. Ajouter un nouveau SPN de sous-domaine kerberos

1. Dans votre environnement Active Directory, ouvrez une invite de commande en tant qu'administrateur.

2. Exécutez la commande suivante pour ajouter un SPN de sous-domaine Kerberos :

   setspn -S HTTP/<yourorg>.kerberos.<oktaorgtype>.com <serviceAccountName>

   Variable	Valeur
   HTTP/<yourorg>.kerberos.<oktaorgtype>.com	Votre SPN.
   oktaorgtype	Le type de votre organisation Okta. Par exemple : oktapreview, okta-emea ou okta-gov.
   serviceAccountName	Le nom de votre compte de service. Il s'agit du nom que vous avez utilisé lors de la configuration de la version en accès anticipé de la SSO de bureau sans agent.

   Exemple :

   setspn -S HTTP/qa-synth.kerberos.oktapreview.com spndefault

   Cette commande ne crée pas de compte utilisateur Active Directory. Au lieu de cela, elle ajoute un nouveau SPN au compte utilisateur AD existant. Cette commande s'applique à l'ensemble des organisations, y compris à celles qui utilisent une URL personnalisée.

3. Si vous disposez de plusieurs forêts AD, répétez l'étape 2 pour chaque forêt.

   Les SPN sont uniques dans une forêt, vous ne devez donc effectuer cette opération qu'une seule fois dans chaque forêt.

2. Vérifier le nouveau SPN du sous-domaine Kerberos

1. Dans Windows Powershell, saisissez la commande suivante pour confirmer que les nouvelles entrées DNS et SPN sont mises à jour :

   klist get HTTP/<yourorg>.kerberos.<oktaorgtype>.com

   Par exemple :

   klist get HTTP/atko.kerberos.oktapreview.com

2. Confirmez que vous recevez le message concernant la récupération réussie du ticket.

   

3. Ajouter le nouveau sous-domaine Kerberos à la zone intranet

Ajoutez https://<yourorg>.kerberos.<oktaorgtype>.com à la liste des sites intranet dans vos paramètres Internet pour tous les appareils qui doivent utiliser l'activation silencieuse.

1. Dans Internet Explorer, rendez-vous dans ParamètresOptions InternetSécurité.
2. Dans l'onglet Sécurité , cliquez sur Sites Intranet locauxAvancé.

3. Ajoutez l'URL de votre org Okta telle que vous l'avez configurée au cours des étapes précédentes.

   https://<yourorg>.kerberos.<oktaorgtype>.com

   Par exemple : https://atkodemo.kerberos.oktapreview.com

4. Cliquez sur Fermer et OK dans les autres options de configuration.

B. Créer et confirmer un enregistrement DNS pour votre organisation

Condition préalable : privilèges d'administrateur de domaine pour définir le SPN.

1. Créer un enregistrement DNS pour votre organisation

Dans Okta Admin Console,

1. Accédez à SécuritéAuthentification déléguée.
2. Sur la page Authentification déléguée, cliquez sur l'onglet Active Directory.

3. Faites défiler vers le bas jusqu'à la section SSO de bureau sans agent et activation silencieuse et cliquez sur Modifier.

4. Si le nom d'utilisateur du compte de service est dans l'ancien format (par exemple : HTTP/<yourorg>.<oktaorgtype>.com), remplacez-le par sAMAccountname ou la partie nom d'utilisateur de l'UPN du compte de service pour lequel vous avez configuré le SPN dans la partie A.

   Le nom d'utilisateur du compte de service est sensible à la casse.

   

5. Sélectionnez Valider les informations d'identification du compte de service lors de l'enregistrement.
6. Cliquez sur Enregistrer.

Cela déclenche la création d'un nouvel enregistrement DNS pour votre organisation. La création d'un nouvel enregistrement DNS peut prendre quelques minutes, ou parfois, quelques heures.

2. Confirmez la création du nouvel enregistrement DNS

Utilisez les commandes dig (Mac) ou nslookup (Windows) suivantes pour confirmer que la nouvelle URL Kerberos est accessible.

Pour Mac

$ dig <yourorg>.kerberos.<oktaorgtype>.com

Par exemple :

OU

Pour Windows

$ nslookup <yourorg>.kerberos.<oktaorgtype>.com

Par exemple :

C. Tester la nouvelle configuration

Conditions préalables

• Compte utilisateur de test auquel est affectée une instance d’application Office 365 et qui fonctionne avec l’ancienne configuration d’activation silencieuse.
• Les informations d'identification suivantes pour le compte utilisateur de test :
  • Domaine : <yourorg>.kerberos.<oktaorgtype>.com
  • ID externe : ID externe de l'organisation dans laquelle se trouve l'utilisateur de test. Vous pouvez le trouver dans le script que vous avez utilisé pour la configuration de l'application WS-Fed de l'organisation.
  • Nom d’utilisateur: partie du nom d’utilisateur de l’UPN de l’utilisateur de test.
  • Mot de passe : mot de passe pour le compte utilisateur de test.
• Permissions de l’administrateur sous Windows.

Procédure

1. Sous Windows, en tant qu’administrateur, exécutez la commande PowerShell suivante :

   Get-ExecutionPolicy

2. Notez la stratégie de sortie. Cette valeur est requise pour la dernière étape de la procédure.

   

3. Définissez la stratégie d'exécution sur Sans restriction en utilisant la commande suivante :

   Set-ExecutionPolicy Unrestricted

   

4. Pour tester un compte utilisateur :

   1. Copiez le script suivant dans un fichier texte et enregistrez le fichier sous Test_windowsTransport.ps1.

      Copier

      param (
      [Parameter(Mandatory=$true,
      HelpMessage="Domain for org. No need to pass Kerberos subdomain.")]
      [string]$domain,
      [Parameter(Mandatory=$true,
      HelpMessage="External id of the Office365 app instance.")]
      [string]$externalId,
      [Parameter(Mandatory=$true,
      HelpMessage="Username for the account on the box that should be used for authentication.")]
      [string]$username,
      [Parameter(Mandatory=$true,
      HelpMessage="Password for the account on the box that should be used for authentication.")]
      [string]$password
      )
       
      $HTTPREQUEST_SETCREDENTIALS_FOR_SERVER = 0;
       
      $path = "app/office365/{0}/sso/wsfed/windowstransport" -f $externalId
      $url = "https://{0}/{1}" -f $domain, $path
      Write-Host ("Url: {0}" -f $url)
       
      $soapPayload =
      @'
      <s:Envelope xmlns:s='http://www.w3.org/2003/05/soap-envelope'
      xmlns:wsa='http://www.w3.org/2005/08/addressing'
      xmlns:wsu='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
      <s:Header>
      <wsa:Action s:mustUnderstand='1'>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue</wsa:Action>
      <wsa:messageID>urn:uuid:099B1123-4E9C-4244-8F51-B92937BFA08E</wsa:messageID>
      <wsa:ReplyTo>
      <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous</wsa:Address>
      </wsa:ReplyTo>
      <wsa:To s:mustUnderstand='1'>{0}</wsa:To>
      </s:Header>
      <s:Body>
      <wst:RequestSecurityToken xmlns:wst='http://schemas.xmlsoap.org/ws/2005/02/trust'>
      <wsp:AppliesTo xmlns:wsp='http://schemas.xmlsoap.org/ws/2004/09/policy'>
      <wsa:EndpointReference>
      <wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
      </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
      <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
      </wst:RequestSecurityToken>
      </s:Body>
      </s:Envelope>
      '@ -f $url
       
      $winHttp = New-Object -Com "WinHttp.WinHttpRequest.5.1"
      $winHttp.open("POST", $url, $false)
       
      $winHttp.SetRequestHeader("Content-Type", "application/soap+xml; charset=utf-8")
      $winHttp.SetRequestHeader("SOAPAction", "http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue")
      $winHttp.SetRequestHeader("x-client-OS", "10.0.14393")
      $winHttp.SetRequestHeader("x-client-SKU", "Win32")
      $winHttp.SetRequestHeader("x-client-Ver", "v2.2.1.28801")
       
      $winHttp.send($soapPayload)
       
      if ($winHttp.Status -ne [int]401) {
      Write-Error ("Received unexpected response status: {0}, expected 401." -f $winHttp.Status)
      }
       
      Write-Host "Received 401 response status."
       
      $winHttp.SetCredentials($username, $password, $HTTPREQUEST_SETCREDENTIALS_FOR_SERVER)
      $winHttp.send($soapPayload)
       
      if ($winHttp.Status -ne [int]200) {
      Write-Error ("Received unexpected response status: {0}, expected 200." -f $http.Status)
      }
       
      Write-Host ("Received {0} response status." -f $winHttp.Status)
       
      $samlTicket = [XML]$winHttp.ResponseText
       
      if (-not $samlTicket.Envelope.Body.RequestSecurityTokenResponse.RequestedSecurityToken) {
      Write-Error ("Response did not contain saml ticket.")
      }
       
      Write-Host ("Valid SAML ticket received.")

   2. Exécutez la commande suivante dans PowerShell :

      Copier

      .\Test_windowsTransport.ps1 -domain <yourorg>.kerberos.<oktaorgtype>.com -externalId <orgexternalid> -username <testusername> -password <-testpassword>    

   3. Confirmez que vous obtenez le message SAML suivant :

      Ticket SAML valide reçu.

      

      Ceci confirme que l'activation silencieuse a réussi pour l'utilisateur de test.

5. Restaurez la stratégie d'exécution à sa valeur d'origine en utilisant la commande suivante :

   Set-ExecutionPolicy <initialPolicy>