alifen's questions

Can anybody offer an explanation for the "use redirection server name" setting in an RDP file? It can be set as either:

use redirection server name:i:1

or

use redirection server name:i:0

I have a small number of clients for whom connections via an RD Gateway > Session Broker > Session Host will fail with 0x607 and a very large number where there are no problems.

For the broken client group, changing this setting from 1 to 0 will allow connections to succeed but I'd like to understand why.

Clients are spread across 3 different partner organisations with their own IT departments, so I will need to build a compelling case if we need to get a change in their environments.

My best guess is that it directs the client to either ignore or consider the FQDN of the connection broker against the certificate presented by either the broker or the target session host...

Thanks in advance!

Terminology

Given the very similar terminology, let me set out the two things I am asking about...

Firstly, Azure Active Directory. This is the directory service that underpins o365. You can sync credentials into it and use it for SSO via SAML and a few other bits, but that is basically it.

Secondly, Azure Active Directory Domain Services. This is much closer to a ADDS as we know it since Windows 2000 (OUs, Group Policy, NTLM, etc.) but provided as-a-service. There are a bunch of limitations (no domain admin rights, no schema extensions, no direct access to DCs) but you can domain-join servers to it in the traditional manner.

Their names being so similar has made for very frustrating Google results when trying to get any information about how they might interact, hence my question here!

My Goal

My goal is to move as much as is possible to the Cloud. I already have Exchange and SharePoint moved via o365 and have my on-premise AD syncing with Azure AD. I want to move all my servers to Azure too and use Azure AD Domain Services rather than build my own DCs as Azure VMs. All of that seems achievable.

My critical requirement: I want a user that logs into their o365 mailbox to do so with the same credentials as they use to login to a server (or service running on a server) that is domain-joined to the Azure AD Domain Services domain.

My Question

How do I achieve that critical requirement?!

Do I 'extend' or 'Upgrade?' my Azure AD instance to an Azure AD DS instance? There doesn't seem to be any option to do so.

Do I somehow sync my Azure AD and Azure AD DS instance? Does this mean building a VM to run the AD Connect tool?

There seems to be almost nothing written on the topic (that I can find!) and so your insights are greatly appreciated!

In Server 2012 R2 it was possible to manually install the RDS Gateway role without needing an entire RDS deployment.

In 2016, the Gateway component is missing - as can be verified by running Get-WindowsFeature in a Powershell prompt. It seems the only way to add the component is to do so after completing a RDS deployment.

Is there another approach that will allow use of RDS Gateway as a standalone component?

Consider that a MS SQL Server instance is executing a long-running query the service is stopped via services.msc or - as it actually happening - a system shutdown triggered by a UPS as the server is in a developing country which experiences rolling power blackouts.

When this happens, the service stays in the 'Stopping' state for some time and CPU and disk I/O remains high for that process.

What happens to the queries that are being run? Are they allowed to complete before the service enters the 'Stopped' state or are they cancelled and rolled back?

Ideally, I am looking for an authoritative source (Microsoft documentation) as the answer as I suspect different behavior depending on a factor unknown to me. i.e. sometimes we see queries roll back, sometimes we see them complete. Perhaps the service makes a call as to how far through the transaction it is and if it is quicker to rollback or complete.

If it makes a difference, this is SQL 2012.

Thanks in advance!

Consider an environment that uses 802.1x PEAP authentication via RADIUS. Typically, this is to authenticate wireless clients.

In this environment there are multiple RADIUS servers and clients will be served by whichever is available.

I have seen two approaches with regard to the server certificate presented to clients.

In the first, the same certificate is configured on each RADIUS server. The CN is something generic, e.g. "wireless.mycompany.com"

In the second, the certificate is different on each server and the CN is the hostname of the server, e.g. "server1.mycompany.com"

My question is: Are both acceptable solutions? What are the pros and cons of each approach?

EDIT: Interested particularly in comments relating to ease of roaming for clients.

Is it possible to delegate permission to "Pre-create Read-only domain controller account" (found on the context menu of the Domain Controllers' OU) to a non-domain admin account?

I am needing to set the userAccountControl property of a user account to include TRUSTED_TO_AUTH_FOR_DELEGATION (0x1000000) and PARTIAL_SECRETS_ACCOUNT (0x04000000).

To set TRUSTED_TO_AUTH_FOR_DELEGATION, the account performing the operation needs to be listed in the "Enable computer and user accounts to be trusted for delegation" setting in the security policy on the domain controller on which the operation is being performed. Once added in, the account can set that flag just fine.

However, setting PARTIAL_SECRETS_ACCOUNT results in access denied for any account other than a domain admin.

My question, then, is can I delegate permission to set the PARTIAL_SECRETS_ACCOUNT flag on an account?