New Version of AADConnect–Version 1.1.180.0

Source – https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

A new version of AADConnect (version 1.1.180.0) is available as of today. 

1.1.180.0

Released: 2016 May

New features:

• Warns and helps you verifying domains if you didn’t do it before running Azure AD Connect.
• Added support for Microsoft Cloud Germany.
• Added support for the latest Microsoft Azure Government cloud infrastructure with new URL requirements.

Fixed issues and improvements:

• Added filtering to the Sync Rule Editor to make it easy to find sync rules.
• Improved performance when deleting a connector space.
• Fixed an issues when the same object was both deleted and added in the same run (called delete/add).
• A disabled Sync Rule will no longer re-enable included objects and attributes on upgrade or directory schema refresh.

Read more at source – https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

Azure Identity Protection

Source – https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/

The Identity Protection team is responsible for preventing hackers and cyber criminals from getting access to user accounts in the Microsoft account (MSA) and Azure Active Directory (Azure AD) services. We safeguard hundreds of millions of unique users across more than 13 billion logins every day.

As a lot of you know, a number of articles were published last week about a Russian hacker offering 272.3 million stolen usernames and passwords. This has received a lot of press coverage so we thought you might be interested to learn how we handle these lists when we discover them.

The first thing to understand is that the vast majority of stolen credentials are acquired when a hacker breaches a vulnerable website that stores passwords in plaintext or uses weak encryption or hashing practices. (Stolen usernames and passwords are also commonly acquired in phishing attacks or malware.) The second thing to understand is that many people use the same username and password with multiple sites.

Taken together, this means that when someone else’s services are hacked, it can put accounts with the same username and password in our system at risk.

Because these kinds of breaches and attacks happen quite frequently, we’ve built a standard set of processes and automated services to make sure our users are always protected.

We discover stolen credentials in a bunch of different ways. Mostly our machine learning systems and algorithms find them before any disclosure, but we also find lists by working with local and national governments, industry partners, security researchers and academic institutions all around the world. We also work closely with Microsoft Digital Crimes Unit, Security Response Center, The Office365 team, The Xbox team and many others who contribute to Microsoft’s Intelligent Security Graph and use the combined results to detect and stop attacks.

When we discover a new list of usernames and passwords, we run them through an automated system that checks to see if any of the credentials match those in our MSA or Azure AD systems by comparing the hashes of the submitted password to the hashed password stored with the actual accounts. The good news is that, most of the time, the credentials passed around by criminals don’t match any accounts in our services because the data in this lists is fabricated or out of date.

For this particular list, 9.62% of the usernames matched an account in our systems. And of those, only 1.03% had a matching password. So overall less than 0.1% of the list had a valid match for username and password in our systems.

But remember, our machine learning systems and algorithms find and automatically protect most compromised credentials before any disclosure. In this case, we had already protected 58.3% of that 0.1% because we had already caught an invalid access attempt or other suspicious activity!

The result? Of all the accounts in this list, 0.042 % of them were actually at risk.

Once we’ve identified the subset of accounts that are vulnerable, our automated mitigations kick in to protect them.

In the case of consumer accounts in MSA, the account is marked as being at risk. The next time the rightful account owner logs in, we interrupt them, require that they verify their identity with a second factor, and then require them to change their password.

It looks like this:

In the case of business accounts in Azure AD, the Azure Active Directory Identity Protection service – currently in public preview – gives corporate IT administrators the option to use the same kinds of automated mitigation policies for their user accounts in Azure AD.

The Azure AD user experience looks like this (note the Wingtip Toys brand here is a placeholder logo):

The cool thing about this is that when we detect a user’s password is compromised, Azure AD admins can have the account automatically locked down and protected before the bad guy can ever use the credentials – just like we do for our Microsoft consumer accounts in MSA.

Here’s a screen shot of the admin console in Azure AD Identity Protection, where admins can see their users at risk:

Drill into specifics:

And set policies to automatically remediate users we find at risk:

Last week, Alex Simons mentioned in this blog that Microsoft had just published our 20^th Security Intelligence Report. In that report we explained that we detect more than 10 million credential attacks every day across our identity systems. This includes millions of attacks every day where the username and password are correct, but we detect that the person attempting to log in is a cyber-criminal.

So while 33 million Hotmail username/password pairs in the wild is definitely important to us, it is a relatively small volume, less than half of what we process in an average week, and a drop in the bucket compared to the more than 4
billion credentials we detected being attacked last year.

We hope this helps you understand how those articles you saw relate to your identity security – and how we’re using credential lists (and a lot of other signals) to keep your account safe.

And hey – if *you* ever want to contribute compromised credentials you’ve found, or any other security issue, secure@microsoft.com is the right place to begin the process of reporting them and beginning a secure transfer. But please, don’t send us creds in email! Once we get your contact info we’ll work with you to make appropriate arrangements.

Read more at source – https://blogs.technet.microsoft.com/ad/2016/05/10/how-we-protect-azuread-and-microsoft-account-from-leaked-usernames-and-passwords/

Advanced Threat Analytics new version 1.6 is now available

Source – https://blogs.technet.microsoft.com/ata/2016/05/05/advanced-threat-analytics-new-version-1-6-is-now-available/

We really love and are proud of what we do: we continue to innovate in order to help you identify advanced persistent threats (APTs) and insider threats in your network before they cause damage. As of today, we are glad to share that Advanced Threat Analytics (ATA) is monitoring over 5 million users and 10 million devices!

I want to personally thank our customers and community for your interest with our solution and more importantly making the leap from the traditional security approach to User and Entity Behavioral Analytics (UEBA) with our solution. Your feedback and input have been essential to our product development.

Today, we are proud to announce that ATA’s new version (1.6) is publicly available. With this blogpost, I would like to share detailed information about this update and explain the exciting new enhancements our team developed.

As pioneers of the UEBA market, we set the bar very high and we are introducing exciting new capabilities and innovation:

• New detections such as
  • Pass-The-Hash, Brute Force and others based on unusual protocol behavior
  • Elevation of privileges
  • Reconnaissance via Net Session enumeration
  • Compromised Credentials via Malicious DPAPI Request
  • Compromised Credentials via Malicious Replication Requests
• New deployment option with the ATA Lightweight Gateway helping with branch sites and IaaS deployments
• New and improved detection engine that significantly improves our performance and scale
• Support for automatic updates and upgrades using Microsoft Updates
• Improvements in third party integration to enrich detection

New Detections

Attackers are constantly evolving and improving their Tactics, Techniques and Procedures (TTPs). This is why one of our focus areas is detecting advanced attacks that are being used “in the wild”. Let’s take a look at some of the new detections we have:

Reconnaissance via Net Session enumeration: Reconnaissance is a key stage within the advanced attackers’ kill chain. Domain Controllers (DCs) function as file servers for the purpose of Group Policy Object distribution, using the SMB (Server Message Block) protocol. As part of the reconnaissance phase, an attacker can query the DC for all active SMB sessions on the server, allowing the user to gain access to all the users and IP addresses associated with those SMB sessions. SMB session enumeration may be used by attackers for targeting sensitive accounts, helping them move laterally across the network.

Compromised credentials via Malicious Replication Request: In Active Directory (AD) environments replication happens regularly between Domain Controllers. An attacker may spoof an AD replication request (sometimes impersonating a Domain Controller) allowing the attacker to retrieve the data stored in AD, including password hashes, without utilizing more intrusive techniques like Volume Shadow Copy.

Compromised Credentials via Malicious DPAPI Request: Data Protection API (DPAPI) is a password-based data protection service. This protection service is used by various applications that store user’s secrets, such as website passwords and file-share credentials. In order to support password-loss scenarios, users can decrypt protected data by using a recovery key which does not involve their password. In a domain environment, attackers can remotely steal the recovery key and use it to decrypt protected data on all of the domain-joined computers.

New deployment option

The ATA Lightweight Gateway is a new deployment option that enables you to deploy the ATA Gateway on the on-premises or IaaS Domain Controllers, removing the need for dedicated hardware and/or port-mirroring configuration. The ATA Lightweight Gateway introduces automatic and dynamic resource management based on the available resources on the DC. This intelligent capability will make sure that the existing operations of the DC will not be affected. In addition, the ATA Lightweight Gateway simplifies the deployment of the ATA Gateway in branch sites where there is a limitation of hardware resources and/or port-mirroring support and reduce the TCO.

Performance and Scale

In this new version of ATA (1.6), the performance and scale were greatly improved, enabling ATA to monitor large enterprise environments. This is possible due to significant improvements we have made in our detection engine. In addition, the changes we’ve made enable us to drastically reduce the storage requirements and now ATA requires x5 less space than the previous versions.

Automatic Updates Support

We know that a security solution should always be up to date. This is why with this new version we are introducing automatic updates to ATA. So no more manual downloads and upgrades!

Starting with this version, all releases will automatically update and upgrade via integration with Microsoft Updates (includes WSUS and SCCM integrations). Updates will include new behavior algorithms, detections, features and hotfixes in a simple and seamless way.

Once available in the Microsoft Update cloud service, or in the on-premises WSUS/SCCM, the ATA Center will automatically identify and download the updates. After the ATA Center is updated, all ATA Gateways (unless configured otherwise) will automatically download and deploy the updates from the ATA Center.

Third Party Integration

We are constantly expanding our support for additional 3^rd party data sources to enrich our detection of insider threats and APTs. In this version we are introducing the Support for IBM QRadar – This new ATA version supports receiving events from IBM QRadar SIEM solution, in addition to the previously supported SIEM solutions (RSA Security Analytics, HP Arcsight and Splunk).

Read more at source – https://blogs.technet.microsoft.com/ata/2016/05/05/advanced-threat-analytics-new-version-1-6-is-now-available/

Azure AD Connect Configuration Documenter

Source – https://github.com/Microsoft/AADConnectConfigDocumenter

AAD Connect configuration documenter is a tool to generate documentation of an Azure AD Connect installation. Currently, the documentation is only limited to the Azure AD Connect sync configuration.

The goal of this project is to:

• To enable quick understanding of the synchronization configuration and “how it happens”!
• To build confidence in getting things right when making changes to the default configuration!!
• To know what was changed when you applied a new build of Azure AD Connect!!!

Prerequisites:

1. .NET Framework 4.5 to be able to run the tool
2. A fair understanding of MIIS 2003 / ILM 2007 / FIM 2010 / MIM 2016 sync engine technical concepts to be able to understand the report.

How to use the tool:

• Download the latest release from the releases tab under the Code tab tab and extract the zip file to an empty local folder on a machine which has .NET Framework 4.5 installed.
  • This will extract the Documenter application binaries along with the sample data files for “Contoso”.
  • Make sure that the tool runs by double-clicking on the cmd file AzureADConnectSyncDocumenter.cmd.
• Export the Server Configuration of your pilot / test Azure AD Connect sync server by running Get-ADSyncServerConfiguration cmdlet defined in ADSync module shipped with Azure AD Connect.

    Import-Module ADSync 

    Get-ADSyncServerConfiguration -Path ""

• Copy the configuration export files produced in the previous step to a folder under the “Data” directory of the Documenter tool.
  • e.g. the “Pilot” configuration files for the customer “Contoso” are provided as a sample under the “Data\Contoso\Pilot” folder.
• If you want to document the changes from a specific baseline, export the server configuration of your baseline / production Azure AD Connect server and copy the output to a folder under the Documenter “Data” directory.
  • e.g. the “Production” configuration files for the customer “Contoso” are provided as a sample under the “Data\Contoso\Production” folder.
• Edit AzureADConnectSyncDocumenter.cmd for the values of “Pilot” and “Production” directories.
  • If you don’t have a baseline / production config, specify the same path as the “Pilot” config.
• Run the updated batch file. Upon successful execution, the generated report will be found in the Documenter “Report” folder.

https://aka.ms/aadConnectConfigDocumenter

Read more at source – https://github.com/Microsoft/AADConnectConfigDocumenter

Azure MFA–Directory Integration Filter

Here are a few options which you can use to filter objects from Active Directory when using  Directory Integration with Azure MFA.  The Azure on-premises MFA  server supports standard LDAP filter.  You can this filter in Directory Integration –> Synchronization –> User Filter:

For example,

if you want to filter or include users based on a group membership, you can use the memberOf attribute with distributedName of the security group as shown below:

(memberof=CN=MFASync,OU=Groups,DC=labanddemo,DC=com)

If you want filter or include users based on an attribute value, you can use (attributename=value) format as shown below:

(department=IT)

You can also use standard logical operator to combine your filter statement:

(|(memberof=CN=MFASync,OU=Groups,DC=labanddemo,DC=com)(department=IT))

http://www.amazon.com/dp/1849687447/?tag=packtpubli-20

Azure MFA – ADFS Adaptor and pfsvcclientclr.dll Error

Problem Statement:

When using 7.0 version of Azure on-premises MFA server, you may receive an event ID 364 with “Could not load file or assembly ‘pfsvcclientclr.dll’ or one of its dependencies. The specified module could not be found” error message. 

Complete Error Message

System.IO.FileNotFoundException: Could not load file or assembly ‘pfsvcclientclr.dll’ or one of its dependencies. The specified module could not be found.

File name: ‘pfsvcclientclr.dll’

   at pfadfs.AuthenticationAdapter.IsAvailableForUser(Claim identityClaim, IAuthenticationContext context)

   at Microsoft.IdentityServer.Web.Authentication.External.ExternalAuthenticationHandler.IsAvailableForUser(Claim identityClaim, IAuthenticationContext authContext)

   at Microsoft.IdentityServer.Web.Authentication.External.ExternalAuthenticationHandler.ProcessContext(ProtocolContext context, IAuthenticationContext authContext, IAccountStoreUserData userData)

   at Microsoft.IdentityServer.Web.Authentication.External.ExternalAuthenticationHandler.Process(ProtocolContext context)

   at Microsoft.IdentityServer.Web.Authentication.AuthenticationOptionsHandler.Process(ProtocolContext context)

   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Resolution:

Install:

1. Visual C++ Redistributable x64 and x86 (https://www.microsoft.com/en-us/download/details.aspx?id=49984 )
2. KB2919355 installed If you are using Windows Server 2012R2 (https://support.microsoft.com/en-us/kb/2919355)

http://www.amazon.com/dp/1849687447/?tag=packtpubli-20

Microsoft Azure Datacenter IP Ranges

Source – https://www.microsoft.com/en-us/download/details.aspx?id=41653

This file contains the Compute IP address ranges (including SQL ranges) used by the Microsoft Azure Datacenters. A new xml file will be uploaded every Wednesday (Pacific Time) with the new planned IP address ranges. New IP address ranges will be effective on the following Monday (Pacific Time). Please download the new xml file and perform the necessary changes on your site before Monday.

Download the XML file from https://www.microsoft.com/en-us/download/details.aspx?id=41653

Updated Version of AADConnect (1.1.110.0)

 

Updated version of AADConnect – Version  1.1.110.0 is available for download now.

https://www.microsoft.com/en-us/download/details.aspx?id=47594

More information and bug fix information can be found in https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

1.1.110.0

Released: 2016 February

Fixed issues:

• Upgrade from earlier releases does not work if installation is not in the default C:\Program Files folder.
• If you install and unselect Start the synchronization process.. at the end of the installation wizard, re-running the installation wizard will not enable the scheduler.
• The scheduler will not work as expected on servers where the date/time format is not US-en. It will also block Get-ADSyncScheduler to return correct times.
• If you installed an earlier release of Azure AD Connect with ADFS as the sign-in option and upgrade, you cannot run the installation wizard again.

1.1.105.0

Released: 2016 February

New features:

• Automatic upgrade feature for Express settings customers.
• Support for the global admin using MFA and PIM in the installation wizard.
  • You need to allow your proxy to also allow traffic to https://secure.aadcdn.microsoftonline-p.com if you use MFA.
  • You need to add https://secure.aadcdn.microsoftonline-p.com to your trusted sites list for MFA to properly work.
• Allow changing the user’s sign-in method after initial install.
• Allow Domain and OU filtering in the installation wizard. This also allows connecting to forests where not all domains are available.
• Scheduler is built-in to the sync engine.

Features promoted from preview to GA:

• Device writeback.
• Directory extensions.

New preview features:

• The new default sync cycle interval is 30 minutes. Used to be 3 hours for all earlier releases. Adds support to change the scheduler behavior.

Fixed issues:

• The verify DNS domains page didn’t always recognize the domains.
• Prompts for domain admin credentials when configuring ADFS .
• The on-premises AD accounts are not recognized by the installation wizard if located in a domain with a different DNS tree than the root domain.

1.0.9131.0

Released: 2015 December

Fixed issues:

• Password sync might not work when you change passwords in AD DS, but works when you do set password.
• When you have a proxy server, authentication to Azure AD might fail during installation or un upgrade on the configuration page.
• Updating from a previous release of Azure AD Connect with a full SQL Server will fail if you are not SA in SQL.
• Updating from a previous release of Azure AD Connect with a remote SQL Server will show the error “Unable to access the ADSync SQL database”.

1.0.9125.0

Released: 2015 November

New features:

• Can reconfigure the ADFS to Azure AD trust.
• Can refresh the Active Directory schema and regenerate Sync Rules.
• Can disable a sync rule.
• Can define “AuthoritativeNull” as a new literal in a Sync Rule.

New preview features:

• Azure AD Connect Health for sync.
• Support for Azure AD Domain Services password synchronization.

New supported scenario:

• Supports multiple on-premises Exchange organizations. See Hybrid deployments with multiple Active Directory forests for more information.

Fixed issues:

• Password synchronization issues:
  • An object moved from out-of-scope to in-scope will not have its password synchronized. This incudes both OU and attribute filtering.
  • Selecting a new OU to include in sync does not require a full password sync.
  • When a disabled user is enabled the password does not sync.
  • The password retry queue is infinite and the previous limit of 5,000 objects to be retired has been removed.
  • Improved troubleshooting.
• Not able to connect to Active Directory with Windows Server 2016 forest-functional level.
• Not able to change the group used for group filtering after initial install.
• Will no longer create a new user profile on the Azure AD Connect server for every user doing a password change with password writeback enabled.
• Not able to use Long Integer values in Sync Rules scopes.
• The checkbox “device writeback” remains disabled if there are unreachable domain controllers.

1.0.8667.0

Released: 2015 August

New features:

• The Azure AD Connect installation wizard is now localized to all Windows Server languages.
• Added support for account unlock when using Azure AD password management.

Fixed issues:

• Azure AD Connect installation wizard crashes if another user continues installation rather than the person who first started the installation.
• If a previous uninstall of Azure AD Connect fails to uninstall Azure AD Connect sync cleanly, it is not possible to reinstall.
• Cannot install Azure AD Connect using Express install if the user is not in the root domain of the forest or if a non-English version of Active Directory is used.
• If the FQDN of the Active Directory user account cannot be resolved, a misleading error message “Failed to commit the schema” is shown.
• If the account used on the Active Directory Connector is changed outside the wizard, the wizard will fail on subsequent runs.
• Azure AD Connect sometimes fails to install on a domain controller.
• Cannot enable and disable “Staging mode” if extension attributes have been added.
• Password writeback fails in some configuration because of a bad password on the Active Directory Connector.
• DirSync cannot be upgraded if dn is used in attribute filtering.
• Excessive CPU usage when using password reset.

Removed preview features:

• The preview feature User writeback was temporarily removed based on feedback from our preview customers. It will be re-added later when we have addressed the provided feedback.

1.0.8641.0

Released: 2015 June

Initial release of Azure AD Connect.

Changed name from Azure AD Sync to Azure AD Connect.

New features:

• Express settings installation
• Can configure ADFS
• Can upgrade from DirSync
• Prevent accidental deletes
• Introduced staging mode

New preview features:

• User writeback
• Group writeback
• Device writeback
• Directory extensions

1.0.494.0501

Released: 2015 May

New Requirement:

• Azure AD Sync now requires the .Net framework version 4.5.1 to be installed.

Fixed issues:

• Password writeback from Azure AD is failing with a servicebus connectivity error.

1.0.491.0413

Released: 2015 April

Fixed issues and improvements:

• The Active Directory Connector does not process deletes correctly if the recycle bin is enabled and there are multiple domains in the forest.
• The performance of import operations has been improved for the Azure Active Directory Connector.
• When a group has exceeded the membership limit (by default, the limit is set to 50k objects), the group was deleted in Azure Active Directory. The new behavior is that the group will remain, an error is thrown and no new membership changes will be exported.
• A new object cannot be provisioned if a staged delete with the same DN is already present in the connector space.
• Some objects are marked for being synchronized during a delta sync although there is no change staged on the object.
• Forcing a password sync also removes the preferred DC list.
• CSExportAnalyzer has problems with some objects states.

New features:

• A join can now connect to “ANY” object type in the MV.

1.0.485.0222

Released: 2015 February

Improvements:

• Improved import performance.

Fixed issues:

• Password Sync honors the cloudFiltered attribute used by attribute filtering. Filtered objects will no longer be in scope for password synchronization.
• In rare situations where the topology had very many domain controllers, password sync doesn’t work.
• “Stopped-server” when importing from the Azure AD Connector after device management has been enabled in Azure AD/Intune.
• Joining Foreign Security Principals (FSPs) from multiple domains in same forest causes an ambiguous-join error.

1.0.475.1202

Released: 2014 December

New features:

• It is now supported to do password synchronization with attribute based filtering. For more details, see Password synchronization with filtering.
• The attribute msDS-ExternalDirectoryObjectID is written back to AD. This adds support for Office 365 applications using OAuth2 to access both, Online and On-Premises mailboxes in a Hybrid Exchange Deployment.

Fixed upgrade issues:

• A newer version of the sign-in assistant is available on the server.
• A custom installation path was used to install Azure AD Sync.
• An invalid custom join criterion blocks the upgrade.

Other fixes:

• Fixed the templates for Office Pro Plus.
• Fixed installation issues caused by user names that start with a dash.
• Fixed losing the sourceAnchor setting when running the installation wizard a second time.
• Fixed ETW tracing for password synchronization

1.0.470.1023

Released: 2014 October

New features:

• Password synchronization from multiple on-premise AD to Azure AD.
• Localized installation UI to all Windows Server languages.

Upgrading from AADSync 1.0 GA

If you already have Azure AD Sync installed, there is one additional step you have to take in case you have changed any of the out-of-box Synchronization Rules. After you have upgraded to the 1.0.470.1023 release, the synchronization rules you have modified are duplicated. For each modified Sync Rule do the following:

• Locate the Sync Rule you have modified and take a note of the changes.
• Delete the Sync Rule.
• Locate the new Sync Rule created by Azure AD Sync and re-apply the changes.

Permissions for the AD account

The AD account must be granted additional permissions to be able to read the password hashes from AD. The permissions to grant are named “Replicating Directory Changes” and “Replicating Directory Changes All”. Both permissions are required to be able to read the password hashes

1.0.419.0911

Released: 2014 September

Initial release of Azure AD Sync.

ead more at source – https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

Azure Authenticator–Unable to add the account

Error:

During activation Azure Authenticator application generates the following error message on Android device. This URL and code works on Apple and Microsoft mobile devices.

Unable to add the account.  We couldn’t add the account as your device does not trust the activation URL.  Please contact your IT administrator

Troubleshooting steps:

1. Try to activate the account using Apple or Microsoft device
2. Verify the URL publishing configuration.  Are you publishing the Microsoft MFA Mobile App using Windows Application Proxy?

Solution / Workaround:

The issue is not really related to MFA or certificate configuration.  The issues is more related to how you publish the Mobile App URL to the internet.   If you are using Web Application Proxy for publishing the URL (http://portal.sivarajan.com/2016/01/azure-mfapublish-mfa-portals-using-web.html), there is an issue with  Server Name Indication (SNI) certifies and Android devices. You can try one of the workaround mentioned in that article.

Other option is to publish the Mobile app URL using some other method as mentioned here – http://portal.sivarajan.com/2016/01/azure-mfapublish-mfa-portals-using-web.html

http://www.amazon.com/dp/1849687447/?tag=packtpubli-20

Azure MFA–Publishing MFA Portals using Web Applicaion Proxy

 

The goal is to publish on premises Microsoft Multi Factor Authentication (MFA) server portals using Web Application Proxy Service (not Azure Application Proxy!) The Microsoft MFA has the following 3 portals:

1. User Portal – The User Portal section allows the administrator to install and configure the Multi-Factor Authentication User Portal.

2. Web Service SDK – The Web Service SDK section allows the administrator to install the Multi-Factor Authentication Web Service SDK.

3. Mobile App – The Mobile App section allows the administrator to configure settings for the Mobile App.  There is also a Mobile App Web Service which needs to be installed to support mobile app activations.

At the end of the configuration, my goal is to provide a single direction URL for User Portal, Web Service SDK and Mobile App shown below:

 

http://www.amazon.com/dp/1849687447/?tag=packtpubli-20