Impress your users with an animated logon page in VMware Identity Manager!

Friday is here! First, credit goes to where credit is due – to my UK colleagues. Subscribe to their Twitter and blog – they are useful, and they don’t spam nonsense!

Now, let’s figure out why it didn’t work for the first time…


New Workspace ONE 19.x Open Enrollment Trainings!

Our training colleagues have just posted the schedule for the NEW open enrollment trainings on Workspace ONE 19.x! Including the Live Online options for those who prefer not to travel (cloud solutions are awesome).

See the schedules and links below. Which one would you take? I am planning to attend the troubleshooting one!


WS1 UEM 1904: Fixing the ObjectGUID warning and improving SAML SSO security

If you use SAML SSO to log into the Workspace ONE UEM (AirWatch) console, you may see this warning after upgrading to 1904. First – don’t panic! Everything still functions!

Now that we’re calm, let’s find out what it is and how to address it. On the menu today:

  • What is this strange warning and why/when is it displayed?
  • How to configure the UEM Console SSO in order to make it go away
  • If you are missing the objectGUID attribute – how to add it for
    • VIDM Connector (direct VIDM integration)
    • ACC (AD Basic integration)

Custom login URL for cloud WorkspaceONE Portal nice and easy

With WorkspaceONE deployed, many users begin their day at the main page of the WS1 Portal. Which, if you are using a cloud version, is usually hosted at a URL like <yourname> (or com/etc for other regions). Many don’t like this and want something like instead. Here’s a short note on how to make it, and make it right!

How to make it …wrong!

Our first thought would be: “Not a problem – I’ll just have a DNS CNAME (alias)!” –>

This will not work. The client traffic WILL be redirected to the IP address of the cloud portal, but the URL in all the HTTP headers will still remain And this is not what WS1 expects. At the minimum you will see this:

A very obvious case of the certificate name mismatch.

How to make it …right!

What we need instead if a proper web redirect (HTTP 301 Moved Permanently code) that will basically tell the browser “go to instead“, including all the necessary HTTP header changes.

One way to do it is to deploy a web server hosting the URL and responding with the HTTP 301 Code. But this is complicated and we need a web server. Is there an easier way?

Maybe. Many cloud DNS hosters offer a WR or Web Redirect type of record. Basically, this is exactly the above web server, but they host it for you, and you manage this as just another DNS record type. Here’s how it looks in my CloudDNS console (they did not pay me for this post, but they are the only sensible free DNS provider I could find)

Example of a WE or Web Redirect record. Click to enlarge.

Now if we go to our short login URL we will see a proper login screen and the following network trace in the browser (here I use Chrome Developer Tools). I believe this is pretty self-explanatory. Note that we also don’t need to touch any SSL certs, cookies or anything else. It. Just. Works.

Permanent 301 redirection for VIDM login URL in browser’s network trace.


Now you know two ways to make the life of your users easier by providing them with a short login URL for their WorkspaceONE portal. One of those ways actually works! 🙂

What is your opinion, do you use shortened names in general or this is just a fad and waste of time? Write below!

Modern mobile security: people or devices? (with Dilbert)

I really like this slide from the IDC presentation for Google’s Enterprise Partner Summit 2019 (available in public access here).

A slide from IDC: The Evolution of Android in the Enterprise (c) IDC

Note that the technical threats begin at position number 7! But the top 6 are dominated by the threats based on the user behaviour (and the lack of proper tools/policies that allow such behaviour)!

Why does that happen? What can be done? Read on to learn more and see some Dilbert!


Device Compliance with Identity Manager – the less obvious implementation details

Everyone likes the idea of Device Compliance checks. It allows us to differentiate between Company-issues, BYOD-enrolled, private and totally foreign devices, assess their security posture and execute access decisions based on this vital data, expanding our Conditional Access options. It is also extremely easy to use, just like that (VIDM Admin Console):

Device Compliance can be easily added to any authentication method …yes


Wrong! Try it yourself and see if it works. In this post we will discuss some of the less obvious, but perfectly logical restrictions that Device Compliance imposes on your selection of authentication methods.