PowerShell – Convert Base 64 to Bytes


[IO.File]::WriteAllBytes($Filename, $bytes)


PowerShell – HTTP Authentication

#Authentication Parameters
#Credential used after initial communication

#Building Authorisation Header for initial communication not used afterwards
$Base64Auth=[System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($Credentials.GetNetworkCredential().username + ":" + $Credentials.GetNetworkCredential().password ))
$BasicCredentials = "Basic " + $Base64Auth

$headers = @{"tenant-code" = $tenantAPIKey; "Authorization"= $BasicCredentials}

$Output = Invoke-RestMethod -Method Post -Credential $Credentials -Uri $URI -Body $Body -ContentType $ContentType -Headers $headers 

PowerShell – Non latin language with REST

#HTTP Headers building
$ContentType= 'application/json; charset=utf-8'
$headers = @{"tenant-code" = $tenantAPIKey; "Authorization"= $BasicCredentials}  

$Message = @{
  MessageBody = "Привет от Камиллы"
  MessageType = "String"

#Convert to JSON Depth at 10 ensure correct convertion for long text
$MessageInJSON = $Message | ConvertTo-Json -Depth 10 

#Convert Message to UTF-8 encoding
$Body = [System.Text.Encoding]::UTf8.GetBytes($MessageInJSON)

#Sending Message using Rest
$Output = Invoke-RestMethod -Method Post -Credential $Credentials -Uri $URI -Body $Body -ContentType $ContentType -Headers $headers

VPN – L2TP Error 809

If you’re using L2TP with IPSec.

Windows doesn’t activate NAT-T by default (Windows 10 included) you need to add a registry key:

To create and configure the


registry value, follow these steps:

  • Log on to the Windows Vista client computer as a user who is a member of the Administrators group.
  • Right Click Start, click Run, type regedit, and then click OK. If the User Account Control dialog box is displayed on the screen and prompts you to elevate your administrator token, click Continue.
  • Locate and then click the following registry subkey:


  • On the Edit menu, point to New, and then click DWORD (32-bit) Value.
  • Type AssumeUDPEncapsulationContextOnSendRule, and then press ENTER.
  • Right-click AssumeUDPEncapsulationContextOnSendRule, and then click Modify.
  • In the Value Data box, type one of the following values:
    • 0
      A value of 0 (zero) configures Windows so that it cannot establish security associations with servers that are located behind NAT devices. This is the default value.
    • 1
      A value of 1 configures Windows so that it can establish security associations with servers that are located behind NAT devices.
    • 2
      A value of 2 configures Windows so that it can establish security associations when both the server and the Windows Vista-based or Windows Server 2008-based VPN client computer are behind NAT devices.
  • Click OK, and then exit Registry Editor.
  • Restart the computer.

Validate that the windows service: IPSec Policy Agent is started.


Source: https://support.microsoft.com/en-us/kb/926179

ADFS Authentication with Office 365

  1. User go to an Office 365 url
  2. User is redirected to Microsoft Federation Gateway (login.microsoftonline.com)
  3. User enter his UPN
  4. UPN is recognized by the MFG as a federated domain
  5. User is redirected to the ADFS Server
  6. User use his Kerberos TGT (Ticket Granted Ticket) ticket to authenticate
  7. ADFS send the TGT ticket to the domain controller
  8. ADFS receive a Service Ticket telling who is the user
  9. ADFS use the Service Ticket to query Active Directory for user attribute (UPN, First Name, Last Name, etc.)
  10.  ADFS build a SAML token with user attribute
  11. ADFS server post this SAML token via User browser to MFG
  12. MFG verifies the SAML token signature to validate that is the right ADFS server
  13. MFG create his own SAML token (UPN is inside)
  14. The MFG SMLA token is post back to Office 365 platform using the user browser
  15. Office 365 look for an account with the user UPN

Web Application Proxy – Pre-authentication feature

This article talk about Web Application Proxy but only on Windows Server 2012 R2, please review TechNet pages for other version.

ADFS Pre-authentication


  1. User access to a proxyfied application
  2. The web proxy contact ADFS to check Relying Part trust rules
  3. ADFS Server send back the validation
  4. The Web Application Proxy ask on behalf of the user to KDC a Kerberos Ticket
  5. The KDC sent back a Kerberos ticket if the user was validated
  6. The WAP forward the Kerberos Ticket to the web application
  7. The web server verify the Kerberos token and send the web page
  8. Proxy Forward the http flow to the user

ADFS Configuration

To do a pre-authentication, you need to add a Non-Claims-Aware application relying party trust.

To do that :

  1. Connect to ADFS Server
  2. Open ADFS Management Console
  3. Go to Relying Party Trust
  4. Then click on Add a Non-Claims-Aware Relying Party Trust
  5. Give a display name
  6. Give a URL Identifier, can put anything but must be unique in your ADFS (not used when doing preauthentication)
  7. You can add Multi-Factor authentication, if needed
  8. Tick open the edit Issuance Authorization Rules
  9. Click Add Rule
  10. Select Permit All Users
  11. Then Next and Finish
  12. You’re done

Kerberos Delegation Configuration

For the Kerberos Delegation you have to add some SPN and configure Kerberos Delegation on Web Application Proxy Active Directory account

N.B: Once the application is configured to use Kerberos, user can still authenticate and use the application using the internal application name


You need to had a SPN of type HTTP on the Active Directory account which running the web application (Machine Account or Service Account) with the internal URL, you can use the machine name as an URL.

Exemple: HTTP/myinternalapplication.mydomain.tld

Configure Kerberos Delegation

  1. Go in Active Directory User an Computers console
  2. Open the Web Application Proxy account
  3. Go in the Delegation tab
  4. Click on Trust this computer for delegation to specified services only
  5. Click on Use Kerberos Only
  6. Click Add
  7. Click on User or Computer
  8. Type the Active Directory account where you have added the SPN
  9. Select the corresponding SPN of type HTTP
  10. Validate everything

Web Application Proxy Configuration

  1. Go in Remote Access Management console
  2. Click on Publish
  3. Select ADFS
  4. Select the Non-Claims-Aware Relying party trust
  5. Give a unique name
  6. Add the external URL
  7. Select the Certificate
    1. Wildcard certificate can be used, subject name must match external URL
  8. Add the internal URL
  9. Add the SPN added previously
  10. Click Publish

Office 365 – Lync User Migration – Move-CsUser : Exception of type ‘Microsoft.Rtc.Management.AD.Helpers.RollbackException’ was thrown

When you migrate a Lync 2013 user to Office 365, an error can occur in the following scenario :

  1. UCS is enabled, by default on Lync 2013 when you have exchange 2013 : https://technet.microsoft.com/en-us/library/jj204963.aspx (Not Supported on Exchange 2010)
  2. You have migrated the user mailbox to the cloud

When you type this command:
Move-CsUser -Identity <user@upn.tld> -Target sipfed.online.lync.com -Credential (Get-Credential) -HostedMigrationOverrideUrl https://admin.online.lync.com/HostedMigration/hostedmigrationservice.svc
You will have the following error:
Move-CsUser : Exception of type ‘Microsoft.Rtc.Management.AD.Helpers.RollbackException’ was thrown

The easy way to avoid this error is to move the Lync part before the user mailbox.

The other way is to force the migration which can cause data loss with the –Force option

Continue reading