오피스 365 레지스트리 - opiseu 365 lejiseuteuli

after migration from Office2016 to O365 Business Standard we realized, that our GPOs partly stopped working. Some googleFU gave the hint, that we´d need at least E3 Plan for those we used the admx templates to work again. Some older GPOs used direct Registry manipulation.

Because some of the old Policies still worked, I started digging into the Registry and found, that everything in [HKCU]Software\Microsoft\Policies has no effect. There are some Keys in [HKCU]Software\Microsoft\Office though, that still had an effect.

For example [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\MailSettings] "DisableSignatures"=dword:00000001 had previously greyed out the Signature field. Now, with O365, you´re able to click "Signature" and then Outlook crashes.

Stuff like [HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Excel\Security\ProtectedView] Does even work as expected.

Is there any (unofficial) documentation for those none-Policies keys?

Thanks for help

• This topic is intended for orgs that implemented the Early Access version of this feature prior to the 2019.09.0 release. If this applies to your org, you must complete this migration procedure.

• If you're implementing this feature for the first time after the 2019.09.0 release, follow the instructions in Office 365 Silent Activation: New Implementations.

This procedure describes how to migrate your registry-key-based Office 365 Silent Activation configuration to the new Kerberos-based configuration. The new configuration uses Kerberos authentication, which eliminates the need for registry keys.

Start this procedure

This procedure includes the following main steps:

A. Create and test a new Kerberos subdomain

B. Create and confirm a new DNS record for your org

C. Test the new setup

• If a Client Access Policy in Office 365 is set to deny web browsers, it will also block the silent activation.
• If your app or Okta sign-on policy requires MFA for web browsers, there will be no MFA when logging in through silent activation.
• SWA sign-on is not supported.

A. Create and test a new Kerberos subdomain

1. Add a new kerberos subdomain SPN

Use the same service account that you're using currently. Changing the service account can cause Silent Activation authentication requests to fail.

1. In your Active Directory environment, open a command prompt as an administrator.

2. Run the following command to add a Kerberos subdomain SPN:

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

   Placeholder

   Value

   HTTP/<yourorg>.kerberos.<oktaorgtype>.com	Your SPN.
   oktaorgtype	Your Okta org type. For example: oktapreview, okta-emea, or okta-gov.
   serviceAccountName	Your service account name. This is the name that you used when configuring the Early Access version of Agentless Desktop SSO.

   Example:

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

   This command doesn't create a Active Directory user account. Instead, it adds a new SPN to the existing AD user account. This command is applicable to all orgs, including those that are using a custom URL.

3. If you have multiple AD forests, repeat step 2 for each forest.

   SPNs are unique across a forest so you only need to do this once in each forest.

2. Verify the new Kerberos subdomain SPN

1. In Windows PowerShell, enter the following command to confirm that the new DNS and SPN entries are updated:

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

   For example:

   klist get HTTP/atko.kerberos.oktapreview.com

2. Confirm that you get the message about successful ticket retrieval.

3. Add the new Kerberos subdomain to intranet zone

Add //<yourorg>.kerberos.<oktaorgtype>.com to the intranet site list in your internet settings for all the devices that should use Silent Activation.

In Internet Explorer:

1. Go to Settings > Internet Options > Security.
2. On the Security tab, click Local Intranet > Sites > Advanced.

3. Add the URL for your Okta org as configured in the earlier steps.

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

   Example: //atkodemo.kerberos.oktapreview.com

4. Click Close and OK on the other configuration options.

B. Create and confirm a new DNS record for your org

Prerequisite: Domain administrator privileges to set the SPN.

1. Create a DNS record for your org

In the Okta Admin Console,

1. Go to Security > Delegated Authentication.
2. On the Delegated Authentication page, click the Active directory tab.

3. Scroll down to the Agentless Desktop SSO and Silent Activation section and click Edit.

4. If the service account username is in the old format (for example: HTTP/<yourorg>.<oktaorgtype>.com), change it to the sAMAccountname or the username part of the UPN of the service account for which you set up the SPN in Part A.

   Service account username is case-sensitive.

5. Select Validate service account credential on save.
6. Click Save.

This triggers the creation of a new DNS record for your org. Creating a new DNS record can take a few minutes, or sometimes, a few hours.

2. Confirm the creation of the new DNS record

Use the following dig (Mac) or nslookup (Windows) commands to confirm that the new Kerberos URL is reachable.

If you don't see a success message, run the command again after a few minutes. Sometimes, record creation can take several hours. Refer to the respective command reference documentation for more information on the output messages.

For Mac

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

For example:

OR

For Windows

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

For example:

C. Test the new setup

Prerequisites

• Test user account that has assigned Office 365 app instance and works with old Silent Activation configuration.
• Following credentials for the test user account:
  • Domain: <yourorg>.kerberos.<oktaorgtype>.com
  • External ID: External ID of the org in which the test user is. You can find this in the script you used for the org's WS-Fed set up.
  • Username: Username part of the test user's UPN.
  • Password: Password for the test user's account.
• Admin permissions on Windows.

Procedure

1. On Windows, as an admin run the following PowerShell command:

   Get-ExecutionPolicy

2. Make a note of the output policy. This value is required for the final step of the procedure.

3. Change the execution policy to Unrestricted using the following command:

   Set-ExecutionPolicy Unrestricted

4. Test a user account:

   1. Copy the following script into a text file and save the file as Test_windowsTransport.ps1.

      Copy

      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 = "//{0}/{1}" -f $domain, $path
      Write-Host ("Url: {0}" -f $url)

      $soapPayload =
      @'
      <s:Envelope xmlns:s='//www.w3.org/2003/05/soap-envelope'
      xmlns:wsa='//www.w3.org/2005/08/addressing'
      xmlns:wsu='//docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
      <s:Header>
      <wsa:Action s:mustUnderstand='1'>//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>//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='//schemas.xmlsoap.org/ws/2005/02/trust'>
      <wsp:AppliesTo xmlns:wsp='//schemas.xmlsoap.org/ws/2004/09/policy'>
      <wsa:EndpointReference>
      <wsa:Address>urn:federation:MicrosoftOnline</wsa:Address>
      </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:KeyType>//schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</wst:KeyType>
      <wst:RequestType>//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", "//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. Run the following command in PowerShell:

      Copy

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

   3. Confirm that you get the following successful SAML message:

      Valid SAML ticket received.

      This confirms that Silent Activation is successful for the test user.

5. Restore the execution policy to the original value using the following command:

   Set-ExecutionPolicy <initialPolicy>

See also

Office 365 Silent Activation: New Implementations

Advanced integration topics for Office 365

Typical workflow for deploying Microsoft Office 365 in Okta