Gearing for Success

Projects are a partnership between the consulting team and the client. Just as we use the post-mortem meeting to improve our internal processes and performance, we also use the information gathered to improve how we can help our customers overcome internal obstacles. That way, we can ensure successful projects that exceed our customers’ expectations.

Introduction to Connectors for Ivanti Identity Director

Photo by metamorworks/iStock / Getty Images


A few of the most frequently asked questions that we receive are the following; “What connectors do you support out of the box (OOTB)?” and “How hard is it to create a connector?”.  In order to answer both these questions, the first thing that needs to be understood is “What is a connector?”. 


Connectors come in two main flavors for Identity Director.  The first type is a Data Import Connector and the second type is an Automation Connector.  The difference is where and how they are used which is explain in the next couple of sections. 


A Data Import Connector is a connector that is used in Identity Director to populate the data warehouse.  As of the 2018.3 release, Identity Director supports Active Directory, CSV files, ODBC connections to databases and Microsoft Azure AD. 

While this looks limited at first glance, CSV and ODBC covers most solutions and only requires a view into the database/dataset and then the fields can be mapped visually.  In addition, this set of connectors cannot be expanded outside of Ivanti development.


Automation Connectors are the most common type of connector that needs to be modified or written.  This type of connector is available in Ivanti Automation and not in Identity Director.  This is the connector that actually “talks” to other products to read and write information.  Unlike most Identity Governance Administration (IGA) products, Identity Director comes with an Automation engine that allows connectors to be written in whatever language you are most comfortable with and does not force you into a specific language (like JAVA) or use something proprietary.

Ivanti Automation comes with connectors OOTB and others that are posted on Ivanti Marketplace.  Most of these connectors are foundational, meaning that they are used to create other more complex connectors.  Examples of the OOTB connectors that are foundational are PowerShell, SOAP, REST and SQL.  Examples of connectors which are not foundational are Active Directory, Exchange, Office 365 and

These connectors come both as “pre-packaged” from Ivanti which cannot be changed but can be viewed.  The other type of Automation connector is a “community” connector which can be viewed and changed.  Both are available on Ivanti’s Marketplace as well as from partners and customers.


Hopefully this provides a little more clarity to what a connector means for Ivanti Identity Director.  In the following weeks, we will examine how to create a connector with a simple example.  Until that time, feel free to contact McGlaun Consulting for more information or head over to the Ivanti Community which has additional resources.

Dave Bryant is the VP of Technology at McGlaun Consulting.

Are Biometrics the Weak Link in MFA?

I’m currently in San Francisco attending Oktane 2019 where multi-factor authentication (“MFA”) is understandably a hot topic.  During yesterday’s Partner Summit and today’s Opening Keynote, something occurred to me.  How secure is a mobile device as a mechanism for MFA?

Before we try to answer that question, let’s first have a quick recap of MFA and its components.  MFA is based on granting access after two or more pieces of evidence are presented.  This can be:

  • knowledge (something the user and only the user knows)

  • possession (something the user and only the user has)

  • inherence (something the user and only the user is)

A good non-IT example is an ATM transaction.   You can withdraw money only after you provide “possession” (the ATM card) and “knowledge” (the PIN code).

In the business world, MFA is leveraged because we want to secure our most critical and sensitive information.  As of 2019, the vast majority of MFA devices are mobile phones.  So, what is my issue with the phone being used as “possession”? 


In the past, mobile phones rarely had passcodes but as more capabilities started being added to the device, security started to become an important topic. 

Enter the PIN

This process includes a 4 (or more) digit number that needs to be entered every time you want to access the device.  While this is relatively secure, people unlock their phone multiple times a day and it caused “too much friction”. 

Enter biometrics

This was designed to make it easier to unlock the device while still providing a layer of security.  Fingerprints or facial recognition are the two most commonly used methods today, and they also have the most issues. 

Still skeptical?  Let’s look at something that isn’t farfetched using a real-life example…

One of my colleagues posted an article on Slack earlier this month called “Vengeful sacked IT bod destroyed ex-employer's AWS cloud“ and it tells the story of Voova employees, Steffan Needham and Andy “Speedy” Gonzalez.  Needham was being right-sized for “below-par performance” and decided that destroying his employer’s Amazon Web Services instances by using Speedy’s login credentials would be a great parting gift.  Notably, the article also states that “MFA could potentially have prevented the attacks altogether”.

Now, let’s start to speculate…

Needlam already knows Speedy’s username and password (as stated in the article).  Let’s assume that Voova’s IT department mandated policies that ensures Speedy’s phone is “secured” with a PIN, fingerprint, and/or facial recognition and also enforces MFA for administrative access into their AWS environment. 

Let’s further assume that Needlam and Speedy are friendly enough that he takes him for drinks after his sacking and Speedy becomes incapacitated in the process.  Needlam can now take Speedy’s credentials, attempt to access AWS, and then hold Speedy’s mobile phone to his face or finger to gain access to the token required for MFA.


Needlam is now in the system regardless of the fact that MFA is enabled and configured properly.

If you think this is unrealistic, give it a try.  Take your phone and hold it up to your face with your eye’s closed to unlock it.  There is no prerequisite of being awake or of sound mind for this to work.

So, what can we do about this?  We could force the PIN code back on the device as a way of authenticating access to the phone, however the genie is now out of the bottle and people will revolt.  Requiring a PIN code every time you want to open your phone is now seen as too manual.  Another solution could be prepending a PIN code during the MFA process such as with hardware tokens.  Personally, I believe the solution is not so much rethinking access into the application but monitoring and mitigating risky behavior inside the application.


Dave Bryant is the VP of Technology at McGlaun Consulting


Leveraging Liquidware Stratusphere UX to Troubleshoot WMI Issues in Windows 10

Windows 10 has proven to be the constantly shifting, evolving, and fluid operating system that Microsoft promised it would be. While these attributes bring various advantages to the table such as frequent driver updates and security enhancements, it also keeps IT Professionals on their toes on bringing challenges to the table.