ERP News

Why Configure Single Sign On with Dynamics GP 2015

1.19K 0

With the introduction of Dynamics GP 2015, the Web Client now supports the ability to authenticate by using your Microsoft “Organizational Account”. To understand the real business value to this new offering, it is important to understand how this fits into the overall larger picture of Identity Management in the Microsoft world and how it relates to the traditional authentication options. First here are some basic background and terms to help make sure we are all referring to the same things.

In the Microsoft Cloud world (Office 365, Azure, Outlook.com, CRM Online, etc.) there are currently two buckets of users identities. They are the “Microsoft account” and the “Organizational account”. The Microsoft account may also be referred to as “For home” or “Personal account” where the Organizational account may also be called your “Work” or “School” Account. They are usually differentiated by separate icons when you log into Microsoft services. The Work or School account (Organizational account) has what looks like an ID badge as its icon. The Microsoft account will typically be the Microsoft Windows logo.

Icons representing the Organizational account vs a Microsoft account

Figure 1: Icons representing the Organizational account vs a Microsoft account

There are numerous places that you can log into Microsoft services on the internet. Therefore, you may see the login options presented a bit differently. Here are a couple examples of logging into various Microsoft Services:

Figure 2: Login options for the Office Online product (products.office.com)

Figure 2: Login options for the Office Online product (products.office.com)

Figure 3: Login options for the Office 365 portal (portal.office.com)

Figure 3: Login options for the Office 365 portal (portal.office.com)

So how does a user obtain or get one account vs the other?  The easiest way to look at this is that anyone on the planet (almost) can set up and create their own Microsoft account. You don’t need to be associated with a company or school to have a Microsoft account.  Your child, parents or grandmother can get or may have a Microsoft account. Your username for a Microsoft account can be almost anything as well. For example it could be someperson@yahoo.com or sillyname@gmail.com or blablabla@outlook.com.  Microsoft does not really care as long as it has not already been registered by another user.

An Organizational account, on the other hand, is created by your associated employer or school/university. You typically cannot setup and create your own “Organizational account.”  It will be provided to you by the organization you are a part of.  Your username here will usually be in the format of your primary work or school email address such as first.last@yourcompany.com or userid@univerisity.edu.  You will also typically use an Organizational account when you log into your work computer, or access work or school hosted assets and resources. Almost always, your Organizational account is created and setup in your organizations “Active Directory.”  Active Directory is the identity management system that the vast majority of businesses use for managing users, groups and computer objects.

The bottom line is that the “Organization” (work or school) manages your Organizational account and YOU manage your Microsoft account.

The next point is that Microsoft has facilitated the ability for an IT Administrator to synchronize your Active Directory identities that your company manages (Organizational accounts) into the “Microsoft Azure Cloud”. The specific Azure Cloud service that stores this identity information is called Azure Active Directory (AAD) and it can store all your on-prem user and group objects. Microsoft provides a synchronization tool called Azure Active Directory Connect, and one of the things it does is keep your identities in sync between your Active Directory servers and Azure Active Directory in the Cloud.  This means when you create a new user in your on-prem Active Directory, it automatically ends up in the Cloud with an Organizational account in Azure Active Directory.

Ok, you say, this is all fine, but what does any of this have to do with Dynamics GP and Single Sign On?  Simply put, when you look at the larger strategic picture of extending your current on-prem identities (Organizational accounts) into the Microsoft Cloud, there are 3 major business drivers for this.

Employees use same identity to log into Cloud services and your corporate on-prem applications and services.

Your employees don’t need another identity setup for every new Cloud service or application that your company embraces. I would argue that doing so undermines and puts at risk much of the advantages and benefits you get by leveraging Cloud services in the first place. In addition, users still need access to their on-prem services in a seamless manner.  Being able to use the same identity and password for accessing both on-prem and Cloud hosted services provides real business value to your users.

Organizational accounts can be used to log into literally thousands of web applications.

The “Active Directory Marketplace” of available applications that can be integrated for authentication and authorization with your organization account is currently just over 2,500 different applications. This provides significant business value by allowing you to onboard and adopt applications and integrate them in a consistent and secure manor using your Organizational account. With the Dynamics GP web client now being included as part of that ecosystem, it simplifies the user experience for accessing Dynamics GP.  Users also have a place to actually see and access all your corporate applications and services, regardless of if they are hosted on-prem or in the Cloud. This place is the Office 365 Application Launcher/My Apps or the Access Panel. Figure 4 shows how your corporate users can have one place to access all their apps from any device.

Figure 4: Single place end users can see all applications they have access to.

Figure 4: Single place end users can see all applications they have access to.

This typical user story will illustrate the various pieces and components that will bring this all together.

Jane is an employee in the accounting department of your company. She has an Active Directory account that was setup by your HR or IT department with all her identity information (UserID, first name, last name, department, phone number, mobile number, employee ID, office location, etc.) Jane also has a laptop or computer as well as a mobile device and accesses various applications and services provided by your company so she can get her work done. Some of these likely applications are:

  • Office (Word, Excel, PowerPoint, Outlook etc.)
  • Corporate Email
  • Corporate Instant Messaging / Chat
  • Accounting application (Dynamics GP)
  • CRM Application (Dynamics CRM / Salesforce etc.)
  • Document collaboration (SharePoint, Box etc.)
  • Electronics Signature app (Docusign, Adobe EchoSign etc.)

Think about this list in light of the applications you access to get your job done. It’s not uncommon for a corporate user to access dozens of different applications. The number of applications in use overall for all users in different departments and roles can reach into the hundreds for a single company. Most applications require user login.  Throw in the fact that many companies are now using applications that are hosted in the Cloud (known as Software as a Service or SaaS) that users need access to and the first thing that needs addressed is what identity Jane will use to log into each application.  Additionally, how does Jane know where to go to find all these “official” corporate applications that she has access to?

Jane is likely logging into her computer (be it a Windows or Mac) as well as many of your corporate applications using her Active Directory account that has been setup in your company Active Directory. She also has a mobile device (smart phone and/or tablet typically) that she also uses to access the applications she needs.  Having the ability to extend your corporate identities into the Cloud, and then integrate the various applications (like Dynamics GP 2015) with Azure Active Directory allowing users to use their “Organizational account” to authenticate, solves a huge problem. Jane can use the same username and password she uses to log into her computer to log into the Dynamics GP web interface. She can also use that same username and password to log into most, if not all, of the corporate and SaaS applications that your company is using, and she doesn’t have to remember or bookmark all the URL’s to each of the apps she has access to. This is the real business value to Dynamics GP, being able to use your “Organizational account” for authentication, compared to the “old pattern” where a separate user ID and password were maintained inside of Dynamics GP for each user.  Obviously, the more places you are managing usernames and passwords for your employees, the higher your security risk is. By consolidating the login experience for users to use their Organizational account that is tied to your corporate identity system (Active Directory), you have a central place to manage and govern each user’s authentication and access options. When Jane leaves employment, you disable her Active Directory account, which replicates to Azure Active Directory, and she is no longer logging into Dynamics GP or any other applications or services that are thus integrated with Active Directory (On-Prem) Or Azure Active Directory (Cloud based applications).

Your business is strategically positioned to leverage new Authentication and Authorization patterns and technologies that are emerging all across the internet.

The writing on the wall shows that the days of buying hardware and software in a Capital Expenditure (CapEX) model are numbered. With so many software vendors moving their solutions to be Cloud hosted Software as a Service (SaaS), there will be a time where you can no longer buy the software and run it on your own. Any SaaS solution out there that understands what I call the renaissance of modern computing understands that businesses want to use their own Organizational identities to log into their service. The SaaS vendor does not have to create and maintain an identity system with usernames, passwords, and all the support that goes along with that. Instead they simply say hey, you assert your users identity to us and we accept that. We will focus on providing a great service, and your identity system (Azure Active Directory) will take care of all the identity and access management components.

Microsoft has truly done a remarkable job at enabling this transformation and is identified as the greatest visionary in the Gartner Identity as a Service (IDaaS) 2015 Magic Quadrant. This has also finally lead to the eroding of what I refer to as the “Microsoft Bubble” where applications and data were all running and hosted inside the corporate data center and users logged into these applications using their Active Directory account. By having Azure Active Directory act as a bridge to extend your on-prem identities into the Cloud, your organization can be strategically positioned to meet the needs of the business as applications and services begin moving into a Cloud-first world.  With Dynamics GP 2015 web client now leveraging this newer “Federated Authentication pattern,” it is all beginning to come together.

Just as a quick note– Windows 10 now supports “domain joining” to Azure Active Directory, which is the final piece of the puzzle to bridging that gap from on-prem data and application access to Cloud applications, be it IaaS, PaaS or SaaS applications. Figure 5 shows the convergence between traditional on-prem applications and new Cloud hosted applications and how Active Directory and Azure Active Directory can work together with your Organizational accounts to facilitate proper access and governance to all your applications.

Figure 5: Integration between On-prem and Off-prem services through Azure AD

Figure 5: Integration between On-prem and Off-prem services through Azure AD

Today, applications and your data are moving outside the typical corporate datacenter, and users need secure access to them from any location, on any device. As a Microsoft partner with expertise in Dynamics GP and Identity Management, JourneyTEAM is uniquely positioned to help you get the most business value from both Dynamics GP and from an overall identity management strategy. We can show how you can truly simplify user access, as well as better secure and govern your data and applications, no matter where that data or application resides today or in the future. Please reach out to us if you are interested in how to put together an overall identity strategy for your company, or more specifically, how Dynamics GP 2015 can be integrated with your Organizational accounts and therefore fit into the overall bigger picture for the authentication and single sign on strategy of your company.

by JourneyTEAM

The post Why Configure Single Sign On with Dynamics GP 2015 appeared first on ERP Software Blog.

Leave A Reply

Your email address will not be published.

*

code