Tuesday, January 5, 2016

Azure AD Delegated App Access Management

Source - http://blogs.technet.com/b/ad/archive/2015/12/17/azure-ad-delegated-app-access-management-is-now-ga.aspx

Earlier this year, we shipped a preview of employee self-service app access for Azure AD to help our enterprise IT customers streamline their app access request and approval processes. This feature allows employees to add more applications in their Azure AD access panel, and allows IT to create optional approval workflows that puts app access grant decision making in the hands of a department lead or other delegated administrator. To everyone who tried and it provided feedback, thank you!

This feature is now generally available as part of Azure AD Premium, and we've added some cool new features to give delegated administrators even more control.

In addition to approving requests, delegated admins now get a control panel in the Azure AD access panel that allows them to see which apps they manage access for, and also directly assign and remove user access to those apps. Here's what the app control panel looks like for Google Apps:

This control panel allows team leads to directly grant app access to employees without IT involvement, and without requiring the employee to file a request.

 

Read more at source - http://blogs.technet.com/b/ad/archive/2015/12/17/azure-ad-delegated-app-access-management-is-now-ga.aspx

Friday, January 1, 2016

Microsoft Most Valuable Professional (MVP) Award

 

Microsoft Most Valuable Professional (MVP) Award – Enterprise Mobility

Perfect start to my 2016.  Received the Microsoft Most Valuable Professional (MVP) award for the 6th time.  https://mvp.microsoft.com/en-us/PublicProfile/4030770?fullName=Santhosh%20%20Sivarajan

Received the following good news this morning.

image

Dear Santhosh Sivarajan,
Congratulations! We are pleased to present you with the 2016 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Enterprise Mobility technical communities during the past year.
Also in this email:

  • About your MVP Award Gift
  • How to claim your award benefits
  • Your MVP Identification Number
  • MVP Award Program Code of Conduct

The Microsoft MVP Award provides us the unique opportunity to celebrate and honor your significant contributions and say "Thank you for your technical leadership."

Patrick Malone
Director
Community & Advocacy Programs
Microsoft

Tuesday, November 24, 2015

Topologies for Azure AD Connect

Source - https://azure.microsoft.com/en-in/documentation/articles/active-directory-aadconnect-topologies/

Here is article from Andreas Kjellman on supported Azure AD Connect topologies.

The objective of this topic is to describe different on-premises and Azure AD topologies with Azure AD Connect sync as the key integration solution. It describes both supported and unsupported configurations.

Legend for pictures in the document:

Description
Icon

On-premises Active Directory forest
AD

Active Directory with filtered import
AD

Azure AD Connect sync server
Sync

Azure AD Connect sync server “Staging mode”
Sync

GALSync with FIM2010 or MIM2016
Sync

Azure AD Connect sync server, detailed
Sync

Azure AD directory
AAD

Unsupported scenario
Unsupported

Single forest, single Azure AD directory

SingleForestSingleDirectory

The most common topology is a single forest on-premises, with one or multiple domains, and a single Azure AD directory (a.k.a. tenant). Azure AD authentication is done with password synchronization. This is the topology supported by the express installation of Azure AD Connect.

Single forest, multiple sync servers to one Azure AD directory

SingleForestFilteredUnsupported

It is not supported to have multiple Azure AD Connect sync servers connecting to the same Azure AD directory even if they are configured to synchronize mutually exclusive set of objects (with the exception of a staging server). This could be attempted because one domain in a forest is not reachable from a common network location or in an attempt to distribute the sync load across several servers.

Multiple forests, single Azure AD directory

MultiForestSingleDirectory

Many organizations have environments that include multiple on-premises Active Directory forests. There are various reasons for having more than one on-premises Active Directory forest deployed. Typical examples are designs with account-resource forests, merger and acquisitions related forests or forests used to outsource data.

When you have multiple forests all forests must be reachable by single Azure AD Connect sync server. The server does not have to be joined to a domain and can be placed in a network DMZ if required to be able to reach all forests.

The Azure AD Connect wizard will offer several options for how to consolidate users so even if the same user is represented multiple times in different forests, the user will be represented only once in Azure AD. There are some common topologies described below. You configure which topology you have by using the custom installation path in the installation wizard and select the corresponding option on the page “Uniquely identifying your users”. The consolidation is only happening for users. If groups are duplicated, these are not consolidated with the default configuration.

Common topologies are discussed in the next section: Separate topologies, Full mesh, and Account-Resource.

In the default configuration delivered by Azure AD Connect sync, the following assumptions are made: 1. Users have only one enabled account and the forest where this account is located is used to authenticate the user. This is for both password sync and for federation; userPrincipalName and sourceAnchor/immutableID will come from this forest. 2. Users have only one mailbox. 3. The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL). If there is no mailbox on the user, then any forest can be used to contribute these attribute values. 4. If you have a linked mailbox, then there is also another account in different forest used for login.

If your environment does not match these assumptions, the following will happen: - If you have more than one active account or more than one mailbox, the sync engine will pick one and ignore the other. - If you have linked mailboxes but no other account, these accounts will not be exported to Azure AD and the user will not be a member of any groups. In DirSync a linked mailbox would be represented as a normal mailbox so this is intentionally a different behavior to better support multi forest scenarios.

Multiple forests, multiple sync servers to one Azure AD directory

MultiForestMultiSyncUnsupported

It is not supported to have more than one Azure AD Connect Sync server connected to a single Azure AD directory (with the exception of a staging server).

Multiple forests – separate topologies

“Users are represented only once across all directories”

MultiForestUsersOnce

MultiForestSeperateTopologies

In this environment, all forests on-premises are treated as separate entities and no user would be present in any other forest. Each forest has its own Exchange organization and there is no GALSync between the forests. This could be the situation after a merger/acquisition or in an organization where each business unit is operating isolated from each other. In Azure AD these forests will be in the same organization and appear with a unified GAL. In this picture, each object in every forest will be represented once in the metaverse and aggregated in the target Azure AD directory.

Multiple forests – match users

Common for all multi-forest scenarios where you select one of the options under “User identities exist across multiple directories” is that distribution and security groups can be found in every forest and can contain a mix of users, contacts, and FSPs (Foreign Security Principals).

FSPs are used in ADDS to represent members from other forests in a security group. The sync engine will resolve the FSP to the real user and represent the security group in Azure AD with all FSPs resolved to the real object.

Multiple forests – full mesh with optional GALSync

“User identities exist across multiple directories. Match using: Mail attribute”

MultiForestUsersMail

MultiForestFullMesh

A full mesh topology allows users and resources to be located in any forest and commonly there would be two-way trusts between the forests.

If Exchange is present in more than one forest, there could optionally be an on-premises GALSync solution representing a user in one forest as a contact in every other forest. GALSync is commonly implemented using Forefront Identity Manager 2010 or Microsoft Identity Manager 2016. Azure AD Connect cannot be used for on-premises GALSync.

In this scenario, identity objects are joined using the mail attribute. As a consequence of this, a user with a mailbox in one forest is joined with the contacts in the other forests.

Multiple Forests – Account-Resource Forest

“User identities exist across multiple directories. Match using: ObjectSID and msExchMasterAccountSID attributes”

MultiForestUsersObjectSID

MultiForestAccountResource

In an account-resource forest topology, you have one or more account forests with active user accounts.

This scenario includes one forest that trusts all account forests. This forest has typically an extended AD schema with Exchange and Lync. All Exchange and Lync services as well as other shared services are located in this forest. Users have a disabled user account in this forest and the mailbox is linked to the account forest.

Office 365 and topology considerations

Some Office 365 workloads have certain restrictions to supported topologies. If you plan to use any of these, please refer to each workload’s supported topologies pages.

Workload

Exchange Online
If there is more than one Exchange organization on-premises (i.e. Exchange has been deployed to more than one forest) then you must use Exchange 2013 SP1 or later. Details can be found here: Hybrid deployments with multiple Active Directory forests

Skype for Business
When using multiple forests on-premises then only the account-resource forest topology is supported. Details for supported topologies can be found here: Environmental requirements for Skype for Business Server 2015

Staging server

StagingServer

Azure AD Connect supports installing a second server in “Staging mode”. A server in this mode will only read data from all connected directories and will therefore have an updated copy of the identity data. In case of a disaster where the primary server fails, it is easy to manually fail over to the second server using the Azure AD Connect wizard. This second server can preferably be located in a different datacenter since no infrastructure is shared with the primary server. Any configuration change made on the primary server must be copied to the second server by you.

A staging server can also be used if you want to test a new custom configuration and the effect it will have on your data. You can preview the changes and adjust the configuration. When you are happy with the new configuration you can make the staging server the active server and set the old active server in staging mode.

This method can also be used if you want to replace the sync server and want to prepare the new one before you shut down the currently active server.

It is possible to have more than one staging server if you want to have multiple backups in different data centers.

Multiple Azure AD directories

Microsoft recommends to have a single directory in Azure AD for an organization. Before you plan to use multiple Azure AD directories these topics cover common scenarios which will allow you to use a single directory.

Topic

Delegation using administrative units
Administrative units management in Azure AD

MultiForestMultiDirectory

There is a 1:1 relationship between an Azure AD Connect sync server and an Azure AD directory. For each Azure AD directory, you will need one Azure AD Connect sync server installation. The Azure AD directory instances are by design isolated and users in one will not be able to see users in the other directory. If this is intended, this is a supported configuration but otherwise you should use the Single Azure AD directory models described above.

Each object only once in an Azure AD directory

SingleForestFiltered

In this topology one AAD Connect Sync server is connected to each Azure AD Directory. The Azure AD Connect sync servers must be configured for filtering so they each have a mutually exclusive set of objects to operate on, for example by scoping each server to a particular domain or OU. A DNS domain can only be registered in a single Azure AD directory so the UPNs of the users in the on-premises AD must use separate namespaces as well. For example, in the picture above three separate UPN suffixes are registered in the on-premises AD: contoso.com, fabrikam.com, and wingtiptoys.com. The users in each on-premises AD domain use a different namespace.

In this topology there is no “GALsync” between the Azure AD directory instances so the address book in Exchange Online and Skype for Business will only show users in the same directory.

With this topology only one of the Azure AD directories can enable Exchange hybrid with the on-premises Active Directory.

The requirement for mutually exclusive set of objects also applies to write-back. This makes some writeback features not supported with this topology since these assume a single configuration on-premises. This includes: - Group writeback with default configuration - Device writeback

Each object multiple times in an Azure AD directory

SingleForestMultiDirectoryUnsupported SingleForestMultiConnectorsUnsupported

It is unsupported to sync the same user to multiple Azure AD directories. It is also unsupported to make a configuration change to make users in one Azure AD to appear as contacts in another Azure AD directory. It is also unsupported to modify Azure AD Connect sync to connect to multiple Azure AD directories.

GALsync by using writeback

MultiForestMultiDirectoryGALSync1Unsupported MultiForestMultiDirectoryGALSync2Unsupported

Azure AD directories are by design isolated. It is unsupported to change the configuration of Azure AD Connect sync to read data from another Azure AD directory in an attempt to build a common and unified GAL between the directories. It is also unsupported to export users as contacts to another on-premises AD using Azure AD Connect sync.

GALsync with on-premises sync server

MultiForestMultiDirectoryGALSync

It is supported to use FIM2010/MIM2016 on-premises to GALsync users between two Exchange orgs. The users in one org will show up as foreign users/contacts in the other org. These different on-premises ADs can then be synchronized to their own Azure AD directories.

Read more at source - https://azure.microsoft.com/en-in/documentation/articles/active-directory-aadconnect-topologies/

Wednesday, November 4, 2015

New Version Of AADConnect

Source - https://github.com/Azure/azure-content/blob/master/articles/active-directory/active-directory-aadconnect-version-history.md

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:

New supported scenario:

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.

Read more at source - https://github.com/Azure/azure-content/blob/master/articles/active-directory/active-directory-aadconnect-version-history.md

Thursday, October 15, 2015

Azure – Domain Controller as a Service

Source - http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx

Azure – Domain Controller as a Service

As many of you know, analyst's estimate that Windows Server Active Directory (AD) is deployed by over 90% enterprises in the world. It is the world's most widely used corporate directory and in the 15 years since AD was first introduced, many organizations have developed and deployed hundreds and thousands of applications that rely on LDAP and other AD APIs such as System.DirectoryServices.

Additionally, Active Directory's Domain join and Group Policy capabilities are some of the most widely used enterprise technologies on the planet. For most organizations they are the standard for managing the access and configuration policies for Windows servers and Windows clients.

So it's no surprise that now that these organizations are looking for ways to use the cloud to improve their economics and deliver new competitive advantage, they are looking for ways to virtualize these applications and servers and move them into IaaS cloud services like Azure.

Unfortunately, these legacy applications, many of which were developed by employees and contractors who no longer work at the company, don't support modern authentication protocols like OAuth2.0 or SAML. So rewriting them to use modern authorization protocols is prohibitively expensive.

To work around this challenge, customers generally take two approaches:

  • Set up a VPN/Expressroute to support a direct connection between these apps and servers deployed in their IaaS cloud service provider of choice and the on-premises corporate AD.
  • Run domain controller VMs in their IaaS cloud service and have those domain controllers synchronize to their on-premises Active Directory servers using a VPN/Expressroute connection.

The approaches present serious challenges in terms of reliability, ease of administration and cost. In the first approach, transient network glitches frequently impact application availability. In the second approach, the costs can be substantial. Administrators need to manage DCs running in VMs – including patching, monitoring, troubleshooting replication, performing backups, ensuring high-availability and SLAs etc.

We built Azure AD Domain Services because we saw firsthand the struggles customers were having here and we were pretty sure we could provide a simple, reliable, cost effective solution.

Introducing Azure AD Domain Services

Azure AD Domain Services provides managed cloud based domain services such as domain join, group policy, LDAP & Kerberos/NTLM authentication in the Azure cloud that are fully compatible with Windows Server Active Directory. With these services, you get the full value of Windows Server AD in the cloud domain, without having to deploy, manage, monitor and patch domain controllers.

And because Azure AD Domain Services is part of your existing Azure AD tenant, users login using the same corporate credentials they use for Azure AD, and you can use existing groups and user accounts to secure access to resources.

Read more at source - http://blogs.technet.com/b/ad/archive/2015/10/14/azure-ad-domain-services-is-now-in-public-preview-use-azure-ad-as-a-cloud-based-domain-controller.aspx

Wednesday, October 14, 2015

Azure Application Proxy - Updates

 

Source - http://blogs.technet.com/b/ad/archive/2015/10/14/the-azure-ad-app-proxy-just-keeps-getting-better-and-better.aspx

It's only been 10 months since the Azure AD App proxy become been generally available and already hundreds of organizations are using it in production to integrate their on-premises and IaaS hosted applications with Azure AD, making them seamlessly available to remote workers all around the world.

Of course behind the scenes, our team has been working day and night to make sure the service runs smoothly and provides a great user experience for those remote workers. And of course we keep on evolving the service and add more functionality to support more and more types of applications, improved reliability and a better admin experience.

In just the last three months we added support for custom domain names, conditional access policies, and Intune NDES, as well as improved portal control, and enhanced monitoring.

Today I'm happy to let you know that all of these capabilities that have been in public preview are now officially GA! We've completed our quality assurance and customers are already using them successfully in their production deployments. Now you can use them every day for your business as well.

Next, I'm excited to announce we are turning on a new public preview of several new capabilities that we've recently added. They will allow you to publish more types of applications and to support more complex and demanding topologies. Read on to learn more about them!

Remote Desktop Support

The Azure AD Application Proxy can now be used with Remote Desktop. These Remote Desktop deployments can reside on-premises or in an IaaS deployment.

Remote Desktop traffic is published through Application Proxy using pass-through authentication. This approach solves the connectivity problem and provides basic security protection such as network buffering, hardened Internet frontend and DDoS protection.

Within the Remote Desktop deployment, the Remote Desktop Gateway needs to be published so that it will convert the RPC over HTTPS traffic to RDP over UDP traffic. Then clients will use their Remote Desktop clients (MSTSC.exe) to access Azure AD Application Proxy which starts a new HTTPS connection to the Remote Desktop Gateway using its connectors. That way, Remote Desktop Gateway will not be directly exposed to the Internet and all HTTPS requests will first be terminated in the cloud.

Here is the overall recommended deployment topology:

Read more about Remote Desktop publishing here.

 

Read more at source - http://blogs.technet.com/b/ad/archive/2015/10/14/the-azure-ad-app-proxy-just-keeps-getting-better-and-better.aspx

Tuesday, October 13, 2015

Azure Roles Based Access Control (RBAC)

Roles Based Access Control (RBAC) for Azure is now GA

Source - http://blogs.technet.com/b/ad/archive/2015/10/12/azure-rbac-is-ga.aspx

Until now, to give people the ability to manage Azure you had to give them full control of an entire Azure subscription. Now, using RBAC, you can grant people only the amount of access that they need to perform their jobs. Download the generally available RBAC command-line management tools or use the Azure Management Portal (preview) to manage access for your production Azure workloads.

When it comes to identity and access, most organizations that are considering using the public cloud are concerned about two things:

  1. Ensuring that when people leave the organization they lose access to resources in the cloud.

  2. Striking the right balance between autonomy and central governance. For example, giving the project teams ability to create and manage virtual machines in the cloud, while centrally controlling the networks to which those virtual machines connect.

Azure Active Directory and Azure RBAC make it simple for you to accomplish these goals. Once you extend your Active Directory to the cloud, using Azure AD - your employees can purchase and manage Azure subscriptions using their existing work identity. These Azure subscriptions automatically connect to your Azure AD for single sign-on and access management. When you disable an AD account, it automatically loses access to all Azure subscriptions connected with your Azure AD.

Read more at source - http://blogs.technet.com/b/ad/archive/2015/10/12/azure-rbac-is-ga.aspx

Wednesday, September 30, 2015

Interview with an MVP, Windows Server Expert, and Wiki Ninja - Santhosh Sivarajan

Source - http://blogs.technet.com/b/wikininjas/archive/2015/09/29/interview-with-an-mvp-windows-server-expert-and-wiki-ninja-santhosh-sivarajan.aspx

Welcome to another edition of Interview with a Wiki Ninja!

This interview is with...

Santhosh Sivarajan

Santhosh Sivarajan-'s avatar

Here are some of his online stats:

  • 327 Wiki articles!
  • 2,399 Wiki Edits
  • 680 Wiki Comments
  • 2,852 Forum Answers
  • 8,331 Forum Posts
  • 127 Gallery Contributions
  • 146,396 Gallery Item Downloads

Wow! That's amazing!

Here are some of Santhosh's top articles:

Now let's get to the interviews!

Who are you, where are you, and what do you do? What are your specialty technologies?

Good morning! My name is Santhosh Sivarajan. I currently work for Edgile Inc where my primary focus is Microsoft Enterprise Mobility Suite (EMS) and technologies.  I am responsible for delivering Microsoft Azure based technologies and solutions for our clients.  Prior to joining Edgile, I was an Architect at Astadia (Formerly Idea Integration) where I lead the Microsoft infrastructure practice group in Texas.

I am an author of 2 books (so far - more coming soonJ) -“Migrating from Windows Server 2008 to 2012” and “Windows Server Security Essentials”.  I usually add my technical notes on to my blog (http://portal.sivarajan.com). In addition, I am a frequent contributor to Microsoft TechNet, MSDN and other community websites.

I am a Microsoft Most Valuable Professional (MVP) in identity/directory services since 2011.

I have a Master’s degree in Computer Information Systems from the University of Houston – Victoria.  I live in Sugarland, Texas with my wife Anjali who is also an IT professional and our three year old daughter Gayathri.

Read more at source - http://blogs.technet.com/b/wikininjas/archive/2015/09/29/interview-with-an-mvp-windows-server-expert-and-wiki-ninja-santhosh-sivarajan.aspx

Wednesday, June 24, 2015

Azure AD Connect is now GA

Source - http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

We are also pleased to announce that Azure AD Connect Health is also now generally available for our growing number of Azure AD Premium customers. Azure AD Connect Health is a cloud based service and a key part of our effort to help you monitor and secure your cloud and on-premises identity infrastructure. In this first release, Azure AD Connect Health provides customers who use ADFS with detailed monitoring, reporting and alerts for their ADFS servers.

Read on more for additional details…

Azure AD Connect

Get Started Quickly and Easily

Azure AD Connect lets you get started using your on premises identities with the cloud quickly and easily.  Via a simple wizard based experience you can:

  • Use Express Settings to connect a single AD forest to the cloud within minutes with just a few clicks!

Read more at source - http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

Thursday, June 18, 2015

Azure AD – SSO Integration and Support for Custom Application

Source - http://blogs.technet.com/b/ad/archive/2015/06/17/bring-your-own-app-with-azure-ad-self-service-saml-configuration-gt-now-in-preview.aspx

When we started building out the SaaS app management capabilities of Azure Active Directory, one of our goals was to provide an app integration experience that didn't require you to be an identity specialist to use. This ultimately led to our development of the Azure AD application gallery, and the concept of "pre-integrated" applications. Admins could select pre-integrated apps that they wanted from the gallery, and then complete a simplified step-by-step procedure to enable single sign-on to those apps.

As we worked with our customers and partners on these app integrations, we learned a lot about the types of applications people needed, and how they needed to be deployed. Some of our learnings included:

  • Customers didn't just need single sign-on to SaaS applications, but also their hosted line-of-business and third-party applications deployed to servers they control
  • Many customers had specialty SaaS applications that were difficult to acquire accounts with and test without a joint effort between the Azure AD team, the customer, and the SaaS app provider
  • Many enterprises appreciated the ability to easily configure SaaS apps from the Azure AD app gallery, but also staff people with plenty of knowledge of federation protocols like SAML, and desire the ability to onboard any apps they need in a self-service fashion

So today our team is pleased to announce the ability to configure any application that supports service provider -initiated sign-in using SAML 2.0 for single sign-on with Azure Active Directory.

This can include custom apps that your organization has developed, third-party web applications that your organization has deployed to servers you control, or SaaS applications that you use but have not yet been on-boarded to the Azure AD application gallery.

If you are using any of these types of applications, and have knowledge of or access to their SAML documentation, then we highly recommend checking this out.

When we started building out the SaaS app management capabilities of Azure Active Directory, one of our goals was to provide an app integration experience that didn't require you to be an identity specialist to use. This ultimately led to our development of the Azure AD application gallery, and the concept of "pre-integrated" applications. Admins could select pre-integrated apps that they wanted from the gallery, and then complete a simplified step-by-step procedure to enable single sign-on to those apps.

As we worked with our customers and partners on these app integrations, we learned a lot about the types of applications people needed, and how they needed to be deployed. Some of our learnings included:

  • Customers didn't just need single sign-on to SaaS applications, but also their hosted line-of-business and third-party applications deployed to servers they control
  • Many customers had specialty SaaS applications that were difficult to acquire accounts with and test without a joint effort between the Azure AD team, the customer, and the SaaS app provider
  • Many enterprises appreciated the ability to easily configure SaaS apps from the Azure AD app gallery, but also staff people with plenty of knowledge of federation protocols like SAML, and desire the ability to onboard any apps they need in a self-service fashion

So today our team is pleased to announce the ability to configure any application that supports service provider -initiated sign-in using SAML 2.0 for single sign-on with Azure Active Directory.

This can include custom apps that your organization has developed, third-party web applications that your organization has deployed to servers you control, or SaaS applications that you use but have not yet been on-boarded to the Azure AD application gallery.

If you are using any of these types of applications, and have knowledge of or access to their SAML documentation, then we highly recommend checking this out.

image

Read more at source - http://blogs.technet.com/b/ad/archive/2015/06/17/bring-your-own-app-with-azure-ad-self-service-saml-configuration-gt-now-in-preview.aspx

Popular Posts

Share

Twitter Delicious Facebook Digg Stumbleupon Favorites More