Passing the AZ-300

Hello all!

Over the past year I’ve been buried in Amazon Web Services (AWS), learning the platform, and working through the certification paths.  As part of my new role at Microsoft, I’ve been given the opportunity to pursue the Microsoft Certified: Azure Solutions Architect Expert.  In the world of multi-cloud who doesn’t want to learn multiple platforms? 🙂

The Microsoft Certified: Azure Solutions Architect Expert certification is part of Microsoft’s new set of certifications.  If you’re already familiar with the AWS Certification track, the new Microsoft track is very similar in that it has three paths.  These paths are Developer, Administrator, and Architect.  Each path consists of two exams, again similar to AWS’s structure of Associate and Professional.

Even though the paths are similar the focus and structure of the first tier of exams for the Microsoft exams differ greatly from the AWS Associate exams.  The AWS exams are primarily multiple choice while the Microsoft first level of exams consists of multiple choice, drag and drop, fill in the blank, case studies, and emulated labs.  Another difference between the two is the AWS exams focus greatly on how the products work and when and where to use each product.  The Microsoft first level exams focus on those topics too, but additionally test your ability to implement the technologies.

When I started studying for the AZ-300 – Microsoft Azure Architect Technologies two weeks I had a difficult time finding good study materials because the exam is so new and has changed a few times since Microsoft released it last year.  Google searches brought up a lot of illegitimate study materials (brain dumps) but not much in the way of helpful materials beyond the official Azure documentation.  After passing the exam this week, I wanted to give back to the community and provide some tips, links, and the study guide I put together to help prepare for the exam.

To prepare for an exam I have a standard routine.

  1. I first start with referencing the official exam requirements.
  2. From there, I take one or two on-demand training classes.  I watch each lesson in a module at 1.2x speed (1x always seems to slow which I think is largely due to living in Boston where we tend to talk very quickly).  I then go back through each module at 1.5x to 2.0x taking notes on paper.  I then type up the notes and organize them into topics.
  3. Once I’m done with the training I’ll usually dive deep into the official documentation on the subjects I’m weak on or that I find interesting.
  4. During the entirety of the learning process I will build out labs to get a feel for implementation and operation of the products.
  5. I wrap it up by adding the additional learnings from the public documentation and labs into my digital notes.  I then pull out the key concepts from the digital notes and write up flash cards to study.
  6. Practice makes perfect and for that I will leverage legitimate practice exams (braindumps make the entire exercise a pointless waste of time and degrade the value of the certification) like those offered from MeasureUp.

Yes, I’m a bit nuts about my studying process but I can assure you it works and you will really learn the content and not just memorize it.

From a baseline perspective, my experience with Microsoft’s cloud services were primarily in Azure Active Directory and Azure Information Protection.  For Azure I had built some virtual networks with virtual machines in the past, but nothing more than that.  I have a pretty solid foundation in AWS and cloud architectural patterns which definitely came in handy since the base offerings of each of the cloud providers are fairly similar.

For on-demand training A Cloud Guru has always been my go to.  Unfortunately, their Azure training options aren’t as robust as the AWS offerings, but Nick Coyler’s AZ-300 course is solid.  It CANNOT be your sole source of material but as with most training from the site, it will give you the 10,000 ft view.  Once I finished with A Cloud Guru, I moved on to UdemyScott Duffy’s AZ-300 course does not have close to the detail of Nick’s course, but provides a lot more hands-on activities that will get you working with the platform via the GUI and the CLI.  Add both courses together and you’ll cover a good chunk of the exam.

The courses themselves are not sufficient to pass the exam.  They will give you the framework, but docs.microsoft.com is your best friend.  There is the risk you can dive more deep into the product than you need to, but reference back to the exam outline to keep yourself honest.  Hell, worst case scenario is you learn more than you need to learn. 🙂  Gregor Suttie put together a wonderful course outline with links to the official documentation that will help you target key areas of the public documentation.

Perhaps most importantly, you need to lab.  Then lab again.  Lab once more, and then another time.  Run through the Quickstarts and Tutorials on docs.microsoft.com.  Get your hands dirty with the CLI, PowerShell, and the Portal.  You don’t have to be an expert, but you’ll want to understand the basics and the general syntax of both the CLI and PowerShell.  You will have fully interactive labs where you’ll need to implement the products given a set of requirements.

Finally, I’ve added the study guides I put together to my github.  I make no guarantees that the data is up to date or even that there aren’t mistakes in some of the content.  Use it as an artifact to supplement your studies as you prepare your own study guide.

Summing it up, don’t just look at the exam as a piece of virtual paper.  Look at it as an opportunity to learn and grow your skill set.  Take the time to not just memorize, but understand and apply what you learn.  Be thankful you work an industry where things change and provides you with the opportunity to learn something new and exercise that big brain of yours.

I wish you the best of luck in your studies and if you have additional materials or a website you’ve found helpful, please comment below.

Thanks!

 

 

 

 

 

 

 

Azure AD Pass-through Authentication – How does it work? Part 2

Welcome back. Today I will be wrapping up my deep dive into Azure AD Pass-through authentication. If you haven’t already, take a read through part 1 for a background into the feature. Now let’s get to the good stuff.

I used a variety of tools to dig into the feature. Many of you will be familiar with the Sysinternals tools, WireShark, and Fiddler. The Rohitab API Monitor. This tool is extremely fun if you enjoy digging into the weeds of the libraries a process uses, the methods it calls, and the inputs and outputs. It’s a bit buggy, but check it out and give it a go.

As per usual, I built up a small lab in Azure with two Windows Server 2016 servers, one running AD DS and one running Azure AD Connect. When I installed Azure AD Connect I configured it to use pass-through authentication and to not synchronize the password. The selection of this option will the MS Azure Active Directory Application Proxy. A client certificate will also be issued to the server and is stored in the Computer Certificate store.

In order to capture the conversations and the API calls from the MS Azure Active Directory Application Proxy (ApplicationProxyConnectorService.exe) I set the service to run as SYSTEM. I then used PSEXEC to start both Fiddler and the API Monitor as SYSTEM as well. Keep in mind there is mutual authentication occurring during some of these steps between the ApplicationProxyConnectorService.exe and Azure, so the public-key client certificate will need to be copied to the following directories:

  • C:WindowsSysWOW64configsystemprofileDocumentsFiddler2
  • C:WindowsSystem32configsystemprofileDocumentsFiddler2

So with the basics of the configuration outlined, let’s cover what happens when the ApplicationProxyConnectorService.exe process is started.

  1. Using WireShark I observed the following DNS queries looking for an IP in order to connect to an endpoint for the bootstrap process of the MS AAD Application Proxy.DNS Query for TENANT ID.bootstrap.msappproxy.net
    DNS Response with CNAME of cwap-nam1-runtime.msappproxy.net
    DNS Response with CNAME of cwap-nam1-runtime-main-new.trafficmanager.net
    DNS Response with CNAME of cwap-cu-2.cloudapp.net
    DNS Response with A record of an IP
  2. Within Fiddler I observed the MS AAD Application Proxy establishing a connection to TENANT_ID.bootstrap.msappproxy.net over port 8080. It sets up a TLS 1.0 (yes TLS 1.0, tsk tsk Microsoft) session with mutual authentication. The client certificate that is used for authentication of the MS AAD Application Proxy is the certificate I mentioned above.
  3. Fiddler next displayed the MS AAD Application Proxy doing an HTTP POST of the XML content below to the ConnectorBootstrap URI. The key pieces of information provided here are the ConnectorID, MachineName, and SubscriptionID information. My best guess MS consumes this information to determine which URI to redirect the connector to and consumes some of the response information for telemetry purposes.Screen Shot 2017-04-05 at 9.37.04 PM
  4. Fiddler continues to provide details into the bootstrapping process. The MS AAD Application Proxy receives back the XML content provided below and a HTTP 307 Redirect to bootstrap.his.msappproxy.net:8080. My guess here is the process consumes this information to configure itself in preparation for interaction with the Azure Service Bus.Screen Shot 2017-04-05 at 9.37.48 PM
  5. WireShark captured the DNS queries below resolving the IP for the host the process was redirected to in the previous step.DNS Query for bootstrap.his.msappproxy.net
    DNS Response with CNAME of his-nam1-runtime-main.trafficmanager.net
    DNS Response with CNAME of his-eus-1.cloudapp.net
    DNS Response with A record of 104.211.32.215
  6. Back to Fiddler I observed the connection to bootstrap.his.msappproxy.net over port 8080 and setup of a TLS 1.0 session with mutual authentication using the client certificate again. The process does an HTTP POST of the XML content  below to the URI of ConnectorBootstrap?his_su=NAM1. More than likely this his_su variable was determined from the initial bootstrap to the tenant ID endpoint. The key pieces of information here are the ConnectorID, SubscriptionID, and telemetry information.
    Screen-Shot-2017-04-05-at-9.35.52-PM
  7. The next session capture shows the process received back the XML response below. The key pieces of content relevant here are within the SignalingListenerEndpointSettings section.. Interesting pieces of information here are:
    • Name – his-nam1-eus1/TENANTID_CONNECTORID
    • Namespace – his-nam1-eus1
    • ServicePath – TENANTID_UNIQUEIDENTIFIER
    • SharedAccessKey

    This information is used by the MS AAD Application Proxy to establish listeners to two separate service endpoints at the Azure Service Bus. The proxy uses the SharedAccessKeys to authenticate to authenticate to the endpoints. It will eventually use the relay service offered by the Azure Service Bus.

    Screen Shot 2017-04-05 at 9.34.43 PM

  8. WireShark captured the DNS queries below resolving the IP for the service bus endpoint provided above. This query is performed twice in order to set up the two separate tunnels to receive relays.DNS Query for his-nam1-eus1.servicebus.windows.net
    DNS Response with CNAME of ns-sb2-prod-bl3-009.cloudapp.net
    DNS Response with IP

    DNS Query for his-nam1-eus1.servicebus.windows.net
    DNS Response with CNAME of ns-sb2-prod-dm2-009.cloudapp.net
    DNS Response with different IP

  9. The MS AAD Application Proxy establishes connections with the two IPs received from above. These connections are established to port 5671. These two connections establish the MS AAD Application Proxy as a listener service with the Azure Service Bus to consume the relay services.
  10. At this point the MS AAD Application Proxy has connected to the Azure Service Bus to the his-nam1-cus1 namespace as a listener and is in the listen state. It’s prepared to receive requests from Azure AD (the sender), for verifications of authentication. We’ll cover this conversation a bit in the next few steps.When a synchronized user in the journeyofthegeek.com tenant accesses the Azure login screen and plugs in a set of credentials, Azure AD (the sender) connects to the relay and submits the authentication request. Like the initial MS AAD Application Proxy connection to the Azure Relay service, I was unable to capture the transactions in Fiddler. However, I was able to some of the conversation with API Monitor.

    I pieced this conversation together by reviewing API calls to the ncryptsslp.dll and looking at the output for the BCryptDecrypt method and input for the BCryptEncrypt method. While the data is ugly and the listeners have already been setup, we’re able to observe some of the conversation that occurs when the sender (Azure AD) sends messages to the listener (MS AAD Application Proxy) via the service (Azure Relay). Based upon what I was able to decrypt, it seems like one-way asynchronous communication where the MS AAD Application Proxy listens receives messages from Azure AD.

    Screen Shot 2017-04-05 at 9.38.40 PM

  11. The LogonUserW method is called from CLR.DLL and the user’s user account name, domain, and password is plugged. Upon a successful return and the authentication is valided, the MS AAD Application Proxy initiates an HTTP POST to
    his-eus-1.connector.his.msappproxy.net:10101/subscriber/connection?requestId=UNIQUEREQUESTID. The post contains a base64 encoded JWT with the information below. Unfortunately I was unable to decode the bytestream, so I can only guess what’s contained in there.{“JsonBytes”:[bytestream],”PrimarySignature”:[bytestream],”SecondarySignature”:null}

So what did we learn? Well we know that the Azure AD Pass-through authentication uses multiple Microsoft components including the MS AAD Application Proxy, Azure Service Bus (Relay), Azure AD, and Active Directory Domain Services. The authentication request is exchanged between Azure AD and the ApplicationProxyConnectorService.exe process running on the on-premises server via relay function of the Azure Service Bus.

The ApplicationProxyConnectorService.exe process authenticates to the URI where the bootstrap process occurs using a client certificate. After bootstrap the ApplicationProxyConnectorService.exe process obtains the shared access keys it will use to establish itself as a listener to the appropriate namespace in the Azure Relay. The process then establishes connection with the relay as a listener and waits for messages from Azure AD. When these messages are received, at the least the user’s password is encrypted with the public key of the client certificate (other data may be as well but I didn’t observe that).

When the messages are decrypted, the username, domain, and password is extracted and used to authenticate against AD DS. If the authentication is successful, a message is delivered back to Azure AD via the MS AAD Application Proxy service running in Azure.

Neato right? There are lots of moving parts behind this solution, but the finesse in which they’re integrated and executed make them practically invisible to the consumer. This is a solid out of the box solution and I can see why Microsoft markets in the way it does. I do have concerns that the solution is a bit of a black box and that companies leveraging it may not understand how troubleshoot issues that occur with it, but I guess that’s what Premier Services and Consulting Service is for right Microsoft? 🙂

Azure AD Pass-through Authentication – How does it work? Part 1

Hi everyone. I decided to take a break from the legacy and jump back to modern. Today I’m going to do some digging into Microsoft’s Azure AD Pass-through Authentication solution. The feature was introduced into public preview in December of 2016 and was touted as the simple and easy alternative to AD FS. Before I jump into the weeds of pass-through authentication, let’s do a high level overview of each option.

I will first cover the AD FS (Active Directory Federation Services) solution. When AD FS is used a solution for authentication to Azure Active Directory, it’s important to remember that AD FS is simply a product that enables the use of a technology to solve a business problem. In this instance the technology we are using is modern authentication (sometimes referred to as claims-based authentication) to solve the business problem of obtaining some level of assurance that a user is who they say they are.

When Azure AD and AD FS are integrated to enable the use of modern authentication, the Windows Services Federation Language (WS-FED) standard is used. You are welcome to read the standard for details, but the gist of WS-FED is a security token service generates logical security tokens (referred to assertions) which contain claims. The claims are typically pulled from a data store (such as Active Directory) and contain information about the user’s identity such as logon ID or email address. The data included in claims has evolved significantly over the past few years to include other data about the context of the user’s device (such as a trusted or untrusted device) and user’s location (coming from a trusted or untrusted IP range). The assertions are signed by the security token service (STS) and delivered to an application (referred to as the relying party) which validates the signature on the assertion, consumes the claims from the assertion, and authorizes the user access to the application.

You may have noticed above that we never talked about a user’s credentials. The reason for that is the user’s credentials aren’t included in the assertion. Prior to the STS generating the assertion, the user needs to authenticate to the STS. When AD FS is used, it’s common for the user to authenticate to the STS using Kerberos. Those of you that are familiar with Active Directory authentication know that a user obtains a Kerberos ticket-granting-ticket during workstation authentication to a domain-joined machine. When the user accesses AD FS (in this scenario the STS) the user provides a Kerberos service ticket. The process to obtain that service ticket, pass it to AD FS, getting an assertion, and passing that assertion back to the Azure AD (relying party in this scenario) is all seamless to the user and results in a true single sign-on experience. Additionally, there is no need to synchronize a user’s Active Directory Domain Services password to Azure AD, which your security folk will surely love.

The challenge presented with using AD FS as a solution is you have yet another service which requires on-premises infrastructure, must be highly available, and requires an understanding of the concepts I have explained above. In addition, if the service needs to be exposed to the internet and be accessible by non-domain joined machines, a reverse proxy (often Microsoft Web Application Proxy in the Microsoft world) which also requires more highly available infrastructure and the understanding of concepts such as split-brain DNS.

Now imagine you’re Microsoft and companies want to limit their on-premises infrastructure and the wider technology mark is slim in professionals that grasp all the concepts I have outlined above. What do you do? Well, you introduce a simple lightweight solution that requires little to no configuration or much understanding of what is actually happening. In come Azure AD Pass-through authentication.

Azure AD Pass-through authentication doesn’t require an STS or a reverse proxy. Nor does it require synchronization of a user’s Active Directory Domain Service password to Azure AD. It also doesn’t require making changes to any incoming flows in your network firewall. Sounds glorious right? Microsoft thinks this as well, hence why they’ve been pushing it so hard.

The user experience is very straightforward where the user plugs in their Active Directory Domain Services username and password at the Azure AD login screen. After the user hits the login screen, the user is logged in and go about their user way. Pretty fancy right? So how does Microsoft work this magic? It’s actually quite complicated but ingeniously implemented to seem incredibly simplistic.

The suspense is building right? Well, you’ll need to wait until my next entry to dig into the delicious details. We’ll be using a variety of tools including a simple packet capturing tool, a web proxy debugging tool, and an incredibly awesome API monitoring tool.

See you next post!