TechOnTip Weblog

Run book for Technocrats

Azure Web App & SSL Certificate Reporting using Powershell

Posted by Brajesh Panda on February 18, 2019

Here you go… download from here.

Still using AzureRM Module. But can be easily converted to Az Module

# Retrieve Azure Web App and Azure Certificate Details.
# Helps to find out which Web Apps are enabled for TLS 1.0 or 1.1 so they can be moved to 1.2
# Helps to find out few other info like if HttpsOnly is enabled, Tags, Cert Thumbprint and Expiry date
# Generates CSV files

#Select-AzureRmSubscription -Subscription "test"

# Pick all subscriptions except Azure AD
$AllSubscription = Get-AzureRmSubscription | ?{$ -inotlike "*Azure Active Directory"}

# Few empty arrays
$AllSSLCerts = @()
$AllWebApps = @()

# Retrieve required info from each subscription
foreach($Subscription in $AllSubscription)
    $null = Select-AzureRmSubscription -SubscriptionId $Subscription.ID

    # Web App SSL Certificates
    $WebAppCerts = Get-AzureRmWebAppCertificate 
    $AllWebAppCerts =  $WebAppCerts | select @{n="SubscriptionName";e={$Subscription.Name}}, FriendlyName, IssueDate, ExpirationDate, `
                                                         Thumbprint, SubjectName,Location, Issuer, @{n="ResourceType";e={$_.Type}}
    # Get Azure Web Apps
    $WebApps = Get-AzureRmWebApp

    # Retreive all Key Value paris from Tags & put them into new attributes i.e. Tag-'Key
    $AllKyes = @()
    foreach($item in $WebApps)
            $AllKyes += $item.Tags.Keys
    $SelectedKeys = $AllKyes | select -Unique | ?{$_ -notlike "hidden*"}
    foreach($key in $SelectedKeys)
            $TagAttribute = "Tag-"+$key
            $WebApps | Add-Member -MemberType NoteProperty -Name $TagAttribute -Value '' -Force

            foreach($item in $WebApps)
                    $Object  = New-Object PSObject -Property $item.tags
                    $item.$TagAttribute = $Object.$key

    # Select Specific Attributes from web apps
    $WebAppsDetails = $WebApps| select @{n="SubscriptionName";e={$Subscription.Name}}, Name, State, Enabled, ResourceGroup, Location, DefaultHostName, Tag-*, httpsOnly, `
                            #@{n="httpsOnly";e={(Get-AzureRmResource -ResourceGroupName $_.ResourceGroup  -ResourceType Microsoft.Web/sites -ResourceName $ -ApiVersion 2016-08-01).Properties.httpsOnly}},`    
                            @{n="minTLSVersion";e={(Get-AzureRmResource -ResourceGroupName $_.ResourceGroup  -ResourceType Microsoft.Web/sites/config -ResourceName $ -ApiVersion 2016-08-01).Properties.minTLSVersion}},`
                            @{n="CertName";e={(Get-AzureRmWebAppSSLBinding -WebAppName $_.Name -ResourceGroupName $_.ResourceGroup).Name}}, `
                            @{n="Thumbprint";e={(Get-AzureRmWebAppSSLBinding -WebAppName $_.Name -ResourceGroupName $_.ResourceGroup).Thumbprint}}, `
                            SubjectName,ExpirationDate, Issuer

    # find out ExpiryDate, SubjectNames, Issuer Name
    foreach($WebApp in $WebAppsDetails)
            $Cert = $AllWebAppCerts |?{$_.Thumbprint -eq $WebApp.Thumbprint}
            $WebApp.ExpirationDate = $cert.ExpirationDate
            $WebApp.SubjectName = $cert.SubjectName
            $WebApp.Issuer = $cert.Issuer

    $AllSSLCerts += $AllWebAppCerts | sort expirationdate
    $AllWebApps += $WebAppsDetails
    Remove-Variable -Name AllWebAppCerts
    Remove-Variable -Name WebAppsDetails
    Remove-Variable -Name WebAppCerts
    Remove-Variable -Name WebApps
$AllSSLCerts | Export-Clixml C:\Scripts\AllSSLCerts2.xml
$AllWebApps | Export-Clixml C:\Scripts\AllWebApps2.xml

$AllSSLCerts | Export-Csv C:\Scripts\AllSSLCerts2.csv -NoTypeInformation
$AllWebApps | Export-Csv C:\Scripts\AllWebApps2.csv -NoTypeInformation

Posted in Powershell | Leave a Comment »

Uptime Downtime

Posted by Brajesh Panda on February 18, 2019

Posted in Mix & Match | Leave a Comment »

Powershell: Check if the current logged on account is Admin or not.

Posted by Brajesh Panda on December 10, 2018

$Identity = [System.Security.Principal.WindowsIdentity]::GetCurrent()
$Principal = New-Object System.Security.Principal.WindowsPrincipal($Identity)
$IsAdmin = $Principal.IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)

If UAC is enabled it will show False.

Posted in Mix & Match | Leave a Comment »

Office 365 Autodiscover

Posted by Brajesh Panda on September 22, 2018

One of the best article I have ever read.


Posted in Mix & Match | Leave a Comment »


Posted by Brajesh Panda on August 22, 2018

If you want save, change and reapply default error action preference.


Posted in Mix & Match | Leave a Comment »

Powershell: Select String except last two characters.

Posted by Brajesh Panda on February 22, 2018


Posted in Mix & Match | Leave a Comment »

Search Multiple Files using Select-String

Posted by Brajesh Panda on November 28, 2017

Get-ChildItem -recurse | Select-String -pattern "blah blah" | Select-Object path ,line,linenumber,filename | Export-Csv -Path C:\Garbage\search-logs.csv -NoTypeInformation

Posted in Powershell | Leave a Comment »

Free Online Training on Azure Data Lake

Posted by Brajesh Panda on September 14, 2017


Get Outlook for iOS

Posted in Mix & Match | Leave a Comment »

SuperMicro ZFS Storage Server

Posted by Brajesh Panda on August 5, 2017

I want one of these!!

Posted in Mix & Match | Leave a Comment »

Slow Code: Top 5 Ways to Make Your PowerShell Scri…

Posted by Brajesh Panda on July 13, 2017

Get Outlook for iOS

Posted in Mix & Match | Leave a Comment »

Office 365 – Exchange Online Protection is so bad!!

Posted by Brajesh Panda on July 10, 2017

After so many years Microsoft’s algorithm cannot catch this kind of phishing emails. Not sure what they doing. AI, Machine Learning… blah blah blah

We were doing a pilot for a 3rd party anti spam product and now we removed the Pilot before we go for negotiation. Now in a week we have 8 major inbound phishing campaign.

Every time you create a ticket with Ms, they will take it like one time incident and at the end recommend submit a copy, block the IP.

As much as I like 365 as a solution, I hate this product.

Posted in Mix & Match | Leave a Comment »

Powershell Error Handling

Posted by Brajesh Panda on July 7, 2017

Posted in Mix & Match | Leave a Comment »

Storage Migration Steps/Blueprint

Posted by Brajesh Panda on June 3, 2017

Discover, Discover & Discover

This is THE key step for migration

  1. Most of the storage systems can produce some level reports for discovery.
  2. Current System Spec, Features
  3. Used Features, if they can be moved or need to be rebuilt in the new one. Like Deduplication, pretty much dependent on storage. You can just simply move to another type of array.
  4. Configuration, registered hosts, their way of registration, attached LUN/volume info, zoning, HBA wwn/iqn details, access details, how volumes are mounted or used by the targeted system.
  5. Raid group/volume/luns/filesystem details, what features are enabled on them
  6. Extended/merged meta volumes if any
  7. Network config details for iSCSI or NFS related targets. Not only basic info but deep info like MTUs, LACP, mode of switch ports, VLANs, isolations, security configs etc.
  8. Client-side multipath software, initiator, driver versions, compatibility with the new system or any upgrade required.
  9. Which software is using the client-side mounts, if anything configured at application level like deduplication, encryption, compression etc.
  10. Client-side environment ownership, server owner, application owner. Talk to them find out criticality of application, who use that volume, number of users, how long outage can be available in the worst case.
  11. Any san level backup tool, cross-site replication tool etc.
  12. Another step I followed in past from project to project is to clean up necessary environment, you may face roadblocks from Application owners because you asking them to clean up their bad job. But it helps to fast-track the process, over the period people dump unnecessary data in volumes, like installable, old backup files etc.
  13. Any OEW support contract, how quickly they respond & what is included in the support.  You may need it to save life 😉

Design, Configure, Trial, Acceptance Testing & Scheduling Plan

  1. Assuming you already have up and running the new system.
    1. If not that’s another animal. If you are consulting to buy a new box, sizing is the key concept you have to look at. And you may like to consider new technologies for better performance or easy technologies to optimize cost and implementation. Like moving from Fiber to iSCSI or traditional SAS/Fiber disk to SSD, 1gbps to 10gbps, getting rid of old brocade switches, introducing infiband ;-). While proposing or buying a new system also look for features and process how to move data from old system to new.
    2. If it is a new system, rack and stack, configurations are another project.
  2. Design data migration solutions
    1. Host registration, multipathing, software if any
    2. Storage to Storage Data Moves by LUN Mirroring/SAN Copy etc. How sans can talk to each other. Is there any native tool available or you need a 3rd party.
      1. No need of downtime
    3. Data migration inside the server, like moving the database from old mounted volume to new or moving virtual infra to new datastores.
      1. May or may not need downtime, depending on application
    4. Plan for reversal procedure, restore procedures
    5. Decommission old LUN/volume by taking out access. Try to avoid quick removal of volumes.
  3. Try out storage migration processes, document and fine tune.
  4. After migration check, if there is any activity in the old system.
  5. Use Dev/Test servers for operational acceptance testing.
  6. Be careful of clustered servers, sometimes they don’t like SAN copy stuff, but you can get around them.
  7. Map out migration steps for each client/applications volumes/luns to new system & success criteria. This is the Operational Run book, which can be used by the operation team to run the show.
  8. Schedule time with application owners and run them thru your plan. Find out when can be done (timings etc) and schedule them into migration calendar, assign application administrators, testers. This will be your project schedule & tracking card.
  9. Assign schedules and run book steps to respecting operation engineers, application engineers, testers. This will be your work breakdown structure to hold responsibilities.

Actual Project execution

  1. Implement necessary change procedure &
  2. Notify each party before starting the job
  3. Work with application owners to achieve the goal
  4. Make sure data backup process moved to the new system.
  5. Sign off


Posted in EMC Storage, Mix & Match | Leave a Comment »

SAML vs OAuth 2.0

Posted by Brajesh Panda on May 8, 2017

Good article by Zach Dennis.

Chances are you’ve logged into an application (mobile app or web app) by clicking on a ‘Log in with Facebook’ button. If you use Spotify, Rdio, or Pinterest, then you know what I’m talking about.

As a user, you likely don’t care about how SSO works. You just want to use an application and can be thankful for a smoother experience and that you have to remember fewer logins and passwords.

In order to provide a user with a single sign on experience a developer needs to implement a SSO solution. Over the years there have been many attempts at achieving SSO, but this article is going to focus on a comparison between SAML and OAuth2 – a recent exploration that we took on (thankfully coming out the other end unscathed, but with a lot of information).

Our Need for SSO

We’re working on a platform which will have several client applications. Some of these applications will be web-based, others will be native, such as mobile apps.

This platform will roll out being accessible to a few different clients (owned by different organizations). Down the road, additional third-party applications are intended to be built around this platform.

The platform is a front end to a large enterprise system that already has identity information about the people who would be interacting with it. Rather than having each client application maintain their own user database with usernames and passwords, it seems more appropriate to utilize SSO.

Single sign on would allow the enterprise system to securely store and own all of the user credentials. The platform can establish a trust relationship with the enterprise authentication server and client applications can be built to utilize the trusted auth server to authenticate users.

Our goal was to identify an SSO strategy and implementation that could support these needs.

Enter SAML 2.0

We originally looked into SAML 2.0 which is a set of open standards, one of which is specifically designed for SSO.

The SAML 2.0 specification (henceforth SAML) provides a Web Browser SSO Profile which describes how single sign on can be achieved for web apps. There are three main players in SAML:

SAML vs. OAuth2 terminology

SAML and OAuth2 use similar terms for similar concepts. For comparison the formal SAML term is listed with the OAuth2 equivalent in parentheses.

  • Service Provider (Resource Server) – this is the web-server you are trying to access information on.
  • Client – this is how the user is interacting with the Resource Server, like a web app being served through a web browser.
  • Identity Provider (Authorization Server) – this is the server that owns the user identities and credentials. It’s who the user actually authenticates with.

The most common SAML flow is shown below:

Here’s a fictitious scenario describing the above diagram:

  • A – a user opens their web-browser and goes to which stores all of their photos. doesn’t handle authentication itself.
  • B – to authenticate the user constructs a SAML Authnrequest, signs it, optionally encrypts it, and encodes it. After which, it redirects the user’s web browser to the Identidy Provider (IdP) in order to authenticate. The IdP receives the request, decodes it, decrypts it if necessary, and verifies the signature.
  • C – With a valid Authnrequest the IdP will present the user with a login form in which they can enter their username and password.
  • D– Once the user has logged in, the IdP generates a SAML token that includes identity information about the user (such as their username, email, etc). The Id takes the SAML token and redirects the user back to the Service Provider (
  • E – verifies the SAML token, decrypts it if necessary, and extracts out identity information about the user, such as who they are and what their permissions might be. now logs the user into its system, presumably with some kind of cookie and session.

At the end of the process the user can interact with as a logged in user. The user’s credentials never passed through, only through the Identity Provider.

There is more detail to the above diagram, but this is high-level of what’s going on.

SAML token vs. SAML Assertion

When first being introduced to SAML, the term "SAML token" came up over and over again. It’s not actually a term in the SAML spec, but people kept using it, and its meaning was elusive.

As it turns out, the term "SAML token" seems to be a colloquial way to refer to the SAML Assertion, often compressed, encoded, possibly encrypted, and it usually looks like gobbly-gook. And a SAML Assertion is just an XML node with certain elements.

SAML’s Native App Limitation

SAML supports the concepts of bindings. These are essentially the means by which the Identity Provider redirects the user back to the Service Provider. For example, in step D above, the user gets redirected back to the, but how?

The two relevant types of bindings are the HTTP Redirect and the HTTP POST binding defined in the SAML 2.0 spec. The HTTP Redirect binding will use a HTTP Redirect to send the user back to the Service Provider, in the case of our example:

The HTTP Redirect binding is great for short SAML messages, but it is advised against using them for longer messages such as SAML assertions. From wikipedia:

Longer messages (e.g., those containing signed SAML assertions) should be transmitted via other bindings such as the HTTP POST Binding.

The recommended way of using an HTTP POST has its own oddities. For example, the SAML specification recommends that step D above renders an HTML form where the action points back to the Service Provider.

You can either have the user click another button to submit that form or you can utilize JavaScript to automate submitting the form. Why is there a form that needs to be submitted? In my opinon, SAML 2.0 is showing it’s age (circa 2005), as the form here only exists so an HTTP POST can be used to send the SAML token back to the Service Provider. Which to SAML’s defense, in 2005, was likely a necessary decision at the time.

This is a problem when the client is not a web-based application, but a native one, such as a mobile app. For example, let’s say we’ve installed the MyPhotos iPhone app. We open the app, and it wants us to authenticate against the Identity Provider. Once we authenticate, the Identity Provider needs to send the SAML token back to the MyPhotos app.

Most mobile applications can be launched via a custom URI, such as, "my-photos://authenticate", and presumably, the Identity Provider submits the form that includes the SAML token to that URL. Our MyPhotos app launches, but we’re not logged in. What gives?

Mobile apps don’t have access to the HTTP POST body. They only have access to the URL use to launch the application. This means that we can’t read the SAML token.

Launching Mobile Apps via URLs

On Android: launching an application from a url using Intents.

On iOS: launching an application by registering a custom URI scheme.

No SAML token, no authenticated user.

Working Around SAML’s HTTP POST Binding

The limitation of the HTTP POST binding for native mobile apps can be worked around. For example, you can use embedded web views, in which you write custom code to watch the entire authentication process. At the very end of the process you scrape the HTML of the page and extract out the SAML token.

A second workaround is to implement a proxy server which can receive the HTTP POST, extract the SAML token, and then make a URL that includes the SAML token (e.g.: "myphotos://authenticate/?SAMLRequest=asdfsdfsdf") The proxy server could then use an HTTP Redirect to cause the device to open the MyPhotos app. And since the SAML token is a part of the URL the MyPhotos app can extract it, and use that to log in.

A third workaround would be to ignore the specification’s recommendation against using the HTTP Redirect binding. This is very tempting, but it’s hard to shake off the feeling that you’re walking into a mine-field, just hoping you don’t make one wrong step.

Another approach which avoided workarounds altogether is to not rely on SAML, but look at another approach, like OAuth 2.0.

Enter OAuth 2.0

Unlike SAML, OAuth 2.0 (henceforth OAuth2), is a specification whose ink has barely dried (circa late 2012). It has the benefit of being recent and takes into consideration how the world has changed in the past eight years.

Mobile devices and native applications are prevalent today in ways that SAML could not anticipate in 2005.

The basic players with OAuth2 are:

SAML vs. OAuth2 terminology

SAML and OAuth2 use similar terms for similar concepts. For comparison the formal OAuth2 term is listed with the SAML equivalent in parentheses.

  • Resource Server (Service Provider) – this is the web-server you are trying to access information on.
  • Client – this is how the user is interacting with the Resource Server. This could be a browser-based web app, a native mobile app, a desktop app, a server-side app.
  • Authorization Server (Identity Provider) – this is the server that owns the user identities and credentials. It’s who the user actually authenticates and authorizes with.

At a high level, the OAuth2 flow is not that different from the earlier SAML flow:

Let’s walk through the same scenario we walked through with SAML earlier:

  • A – a user opens their web-browser and goes to which stores all of their photos. doesn’t handle authentication itself, so the user is redirected to the Authorization Server with a request for authorization. The user is presented with a login form and is asked if they want to approve the Resource Server ( to act on their behalf. The user logs in and they are redirected back to
  • B – the client receives an authorization grant code as a part of the redirect and then passes this along to the client.
  • C – the Client then uses that authorization grant code to request an access token from the Authorization Server.
  • D – if the authorization grant code is valid, then the Authorization Server grants an access token. The access token is then used by the client to request resources from the Resource Server (
  • E – receives the request for a resource and it receives the access token. In order to make sure it’s a valid access token it sends the token directly to the Authorization Server to validate. If valid, the Authorization Server sends back information about the user.
  • F – having validated the user’s request sends the requested resource back to the user.

This is the most common OAuth2 flow: the authorization code flow. OAuth2 provides three other flows (or what they call authorization grants) which work for slightly different scenarios, such as single page javascript apps, native mobile apps, native desktop apps, traditional web apps, and server-side applications where a user isn’t directly involved but they’ve granted you permission to do something on their behalf.

The big advantage with OAuth2 flows are that the communication from the Authorization Server back to the Client and Resource Server is done over HTTP Redirects with the token information provided as query parameters. OAuth2 also doesn’t assume the Client is a web-browser whereas the default SAML Web Browser SSO Profile does.

Native mobile applications will just work out of the box. No workarounds necessary.

OAuth2’s Favorite Phrase: Out of Scope

The OAuth2 specification doesn’t prescribe how the communication between the Resource Server and the Authorization Server works in a lot of situations, such as validating a token. It also doesn’t say anything about what information should be returned about the user or in what format.

There are quite a few spots where the OAuth2 specification states that things are "outside the scope of this specification." This has brought criticism to the OAuth2 spec because it leaves a lot of things up to implementation which could lead to incompatible implementations at some point.

OAuth2, is still very young, and it already has widespread adoption with the likes of Google, Facebook, Salesforce, and Twitter to name a few. The true beauty of OAuth2 though is its simplicity. In fact, the OpenID Connect Basic Profile, which builds on OAuth2 fills in some of the areas that the OAuth2 spec itself doesn’t define.

OAuth2: Not Requiring Digital Signatures By Default

OAuth2 doesn’t require signing messages by default. If you want to add that in, feel free, but out of the box, the spec works without it. It does prescribe that all requests should be made over SSL/TLS.

This has caused commotion in the past:

Having worked with OAuth2 and OAuth1 in the past, I can say that OAuth2 is much simpler than OAuth1 (and more enjoyable to work with). Interoperability and automatic discovery of services may be something useful in the future, but right now, it’s not anything we’re looking for.

We may be asked to sign messages once the security team of the enterprise does final auditing of the OAuth2 implementation, but for now, OAuth2 fits our current goals in a more standardized manner than SAML. It’s also far simpler.

Who’s Got Your Keys?

If every application has a secured web-server backing it then signing works great, but when that’s not the case the problem becomes more nuanced. How do you securely store your keys in the browser for browser-based JS apps or in native mobile apps?

If you google decompiling iOS and Android apps have your heart will sink. Your keys really aren’t that secure if you can’t own and secure the device.

OAuth2 is for Authorization, not Authentication

The "auth" in OAuth does stand for "Authorization" and not "Authentication". The pedant in you may be smiling. You’ve got me!

But – yes, there’s always a but! Even though the term OAuth is fairly recent, the fact that "auth" meant authorization seems a tad bit anachronistic. It’s already being used to achieve SSO out in the wild (thanks to the likes of Facebook, Twitter, Salesforce, and Google and thousands of sites using them for authenticating and authorizing users).

The biggest complaint I’ve seen is in lack of prescription and the plentiful "out of scope" usages in the OAuth2 spec. The fact that the OpenID Connect Basic Profile is built directly on top of OAuth2 should be enough to dispel the myth that OAuth2 can’t be used for authentication.

What a word meant six years ago is much less important than what it can encompass today.


SAML has one feature that OAuth2 lacks: the SAML token contains the user identity information (because of signing). With OAuth2, you don’t get that out of the box, and instead, the Resource Server needs to make an additional round trip to validate the token with the Authorization Server.

On the other hand, with OAuth2 you can invalidate an access token on the Authorization Server, and disable it from further access to the Resource Server.

Both approaches have nice features and both will work for SSO. We have proved out both concepts in multiple languages and various kinds of applications. At the end of the day OAuth2 seems to be a better fit for our needs (since there isn’t an existing SAML infrastructure in place to utilize).

OAuth2 provides a simpler and more standardized solution which covers all of our current needs and avoids the use of workarounds for interoperability with native applications.

As this begins to unfold and we work with various security teams we’ll see how far this holds up.

So far, so good.

Posted in Mix & Match | Leave a Comment »

ADFS SAML Claim: Windows Domain Name (NetBIOS)

Posted by Brajesh Panda on March 28, 2017

As there are no attributes in Active Directory which can show you which domain the user account belongs to, I have designed my SAML claim rules to retrieve NetBios name of the Active Directory Domain Name.

Edit: June/14/2017:  Well there is an easy way to do it. Use Windows Account Name & Name claim from ADFS. These two provides NetBIOS name in the claims; like domain\samaccountname. Then you can use this to strip out \samaccountname. But to pass these two in your claim, you have to create a passthru claim rule.

  1. Create a new claim description
    1. ADFS Management Console – Service – Claim Description – Create a new
    2. Give a name,
    3. Supply Claim Type, like http://custom.techontip.dom/adattribute/windowsdomainname
  2. Claim Rule 1: Create a Claim Rule to capture / add all AD groups into claim

c:[Type == “;, Issuer == “AD AUTHORITY”]

=> add(store = “Active Directory”, types = (“”), query = “;tokenGroups(domainQualifiedName);{0}”, param = c.Value);

  1. Claim Rule 2: Select Only one group. Here I will select Domain\Domain Users Group.

c:[Type == “;, Value =~ “(?i)Domain Users“]

=> issue(claim = c);

  1. Claim Rule 3: Use RegexReplace to replace \Domain Users and pass on the remaining value to newly created claim description

c:[Type == “;, Value =~ “(?i)Domain Users”]

=> issue(Type = “”, Value = RegexReplace(c.Value, “\\[^\n]*”, “”));

Claim rules need to be in order.

In Claim rule 2: “(?i) means not case sensitive

In Claim rule 3: “\\[^\n]*”; means 1st back slash and everything after it. To capture the black shlash you have to mention two back slashes (\\) but if it is other special character like , or @ no need of double characters.

Here is a nice article about RegEx in Claim rule

Posted in Mix & Match | 2 Comments »

%d bloggers like this: