Next task was setting the reservation to existing VMs deployed into my cloud service. After removing, find image not in use then re-provision passing the parameters into the New-AzureVM using the –ReservedIPName switch. See example:

$vm = New-AzureVMConfig -Name $name -InstanceSize A5 -DiskName (Get-AzureDisk | where {$_.AttachedTo -like ''}).DiskName | `
Add-AzureEndpoint -Protocol tcp -LocalPort 443 -PublicPort 443 -Name "HTTPS" | Set-AzureSubnet $subnet
New-AzureVM -ServiceName $cloudService -Location $location -VNetName $vnet -VMs $vm -ReservedIPName $vip.ReservedIPName -Verbose

Reference links for more details:

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-reserved-public-ip/

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-reserved-public-ip/#how-to-manage-reserved-vips

Ver. 4.0.1752.10000 (SP1)

Ver. 4.0.1773.10100 (SP1U1)

Ver. 4.0.2095.10000 (SP2)

Ver. 4.0.3123.10000 (SP3)

UAG-KB2585140 – UAG Service Pack 1 Update 1

TMG-KB2555840 – TMG Service Pack 2

TMG-KB2689195 – TMG Rollup 2 for TMG SP2

TMG-KB980674 – TMG Array Hotfix

UAG-KB2710791 – UAG Service Pack 2

UAG-KB2744025 – UAG Service Pack 3

In any case the installations of UAG service packs fail due to a premature error, be sure you are running the installers as administrators. The second thing to do is enable verbose logging during the installation.

The error is because the schema upgrade operations are timing out. To extend, temporarily increase the value by modifying the machine.config file located within C:\Windows\Microsoft.NET\Framework64\v2.0.050727\CONFIG by adding the following element just before the </configuration> tag. Re-run the service pack to install.  

Reference KB2811066 for fix.

Within the eventlogs, the following error is reported: "ERR_: MMS(6968): d:\bt\9394412\private\source\miis\shared\utils\libutils.cpp(10364): Unusual error code reported 0x80070057. Forefront Identity Manager 4.1.2273.0". There is also traces of the ' 0 is not a valid DN depth' error.”

The following R2 hotfix resolves the “0 is not a valid DN depth” error. The hotfix is located here or can be found by searching on KB2734159.

• TMG KB980674 (An IPsec VPN site-to-site tunnel or a PPTP VPN site-to-site tunnel does not work if you enable integrated NLB on a TMG array
• TMG KB2689195 (TMG SP2 Rollup 2)
• TMG KB2555840 (TMG SP2)
• UAG KB2585140 (UAG SP1 Update 1)

Reference the following TechNet articles related to the topic of this post:

• Publishing SSTP in UAG
• UAG Array and Network Load Balancing

Additionally, make sure your private managed network does not overlap with the address pools allocated for VPN clients.

static private string ConvertBase64ToGuid(string myData)
 {
 byte[] encodeAsBytes = System.Convert.FromBase64String(myData);
 string returnValue = new Guid(encodeAsBytes).ToString();
 return returnValue;
 
 }

Where is this applicable?  Say you have a resource forest where FIM resides so how do you provide access to the portal from autonomous security realms without having to create a bunch of NT trusts or maintaining secondary credentials. Because shadow accounts exist within the resource forest as security principals for dependent services (for example BPOS or O365), you can leverage UAG, ADFS, and KCD together to provide secure access. UAG is claims-aware and supports Kerberos protocol extensions for (1) protocol transitioning and (2) constrained delegation.

• Protocol transition is a Kerberos extension introduced in Windows 2003 which allows a service that uses Kerberos to obtain a Kerberos service ticket on behalf of a Kerberos principal to the service without requiring the principal to initially authenticate to the KDC with credentials.
• Constrained delegation is an extension which allows a service to obtain service tickets (under the delegated users identity) to a subset of other services after it has been presented with a service ticket that is obtained either through the TGS_REQ protocol, as defined in IETF RFC 1510, or in the protocol transition extension.

The architecture should look and works as diagramed below:

To get this working you need the following:

1. Kerberos-enabled WSS 3.0 (FIM Portal Server) + working FIM 2010 installation
2. ADFS 2.0 Server (STS-RP and STS-IP)
3. UAG 2010 SP1

There are many online references for configuring WSS for Kerberos; therefore, I’m just going to summarize the key configuration tasks and troubleshooting notes.

Configuring WSS for Kerberos

1. Reference the following TechNet article to configure Kerberos authentication within WSS:
   • Configure Kerberos Authentication (Office SharePoint Server)
2. Insure Kerberos enabled end-to-end:
   • Run the following query to determine Kerberos is being used for SQL:
     • SELECT SESSION_ID,AUTH_SCHEMA,NET_TRANSPORT FROM SYS.DM_EXEC_CONNECTIONS WHERE @@SSPID = SESSION_ID
     • Verify Kerberos is being used on the WSS Web Front-end event logs. You should be able to filter the log to Event ID: 4624.
       • You can also use Fiddler to validate WWW-Authentication from the client browser to IIS.
3. Once you’re sure Kerberos is configured end-to-end within WSS, you should be good to proceed.

Configure UAG with ADFS 2.0

For the ADFS and UAG configuration make sure the common pre-requisites are configured properly. What I’m referring to is name resolution, certificates, and a working configuration. To insure this, I recommend configuring a sample claims-aware application to insure ADFS is working. This can be accomplished by using any of the step-by-step guides published by the PG.

• ADFS 2.0 Step-by-Step and How To Guides

The next step is to create a portal trunk in UAG and wire it up to the STS.

1. Within the UAG Management Tool, add an ADFS Authentication Server.
2. Specify the URL of the federation metadata and select the “Retrieve Metadata” button.
   • Select the claim value to be used as lead user value. I used Name but this can be something like UPN or Windows Account Name; whatever you want really.
3. Create a portal trunk which will use ADFS as an authentication mechanism.
4. Save and activate the configuration. The next step would be configuring UAG as an RP in ADFS.
   • Verify the federation metadata on UAG and save it to a file for later use.
5. Configure UAG as an RP Trust in ADFS. To do this, you will need to import the federation metadata from the file created in the previous step.
6. Edit the Claims Rules to pass data from the attribute store. In my configuration, the minimum was SAM-Account-Name mapping to Name. Save and test the configuration.
7. As a test, you should attempt to access the UAG Portal. You should be redirected to your IDP. If you have more than one identity provider, then the requestor will need to select their IdP within the HRD page. Otherwise, you should get the FBA login page presented by the IdP. Enter the appropriate credentials to successfully authenticate and be redirected to the RP (UAG Portal). The RP will consume the AuthN token and the end result is to successfully long into the UAG Portal.

Publish FIM through UAG

Now that requestors can successfully log into UAG using Federated AuthN, the next step is to publish FIM 2010 as an application within UAG.

1. Add an application within the existing trunk. UAG comes with a template to use with FIM 2010.
2. Specify the URL for FIM under the web servers’ properties.
3. Enable SSO under the authentication properties. Select “Use Kerberos constrained delegation for single sign-on. Additionally, select a value from this claim type as the shadow account user name for KCD when using federated authentication.The final step is to configure the SPNs in Active Directory for KCD to the UAG server object. Using the UAG Management Tool, Export KCD Settings to Active Directory. Then use Ldifde.exe to import the SPN value which is set on the msDS-AllowToDelegateTo attribute of the UAG computer object.
   • I prefer publishing applications directly through UAG. To do this, uncheck “Add portal and toolbar link” and “Open in a new window” within the Portal Link properties. Within the Portal Trunk configuration, I modify the “Portal home page” to the FIM Application and uncheck “Display home page within portal frame. Assuming, the FIM SPNs are configured properly…we can assume a working FIM Portal.
4. The final step is to test the configuration. Browse the FIM URL from an untrusted workstation outside of the network. The end result is the FIM Portal being rendered in the same way as if you were accessing it internally.

Note: Verify the KCD Protocol Transition is successful and Set KCD Shadow User Name through Web Monitor | Event Viewer | Security Events.