ServiceNow and Active Roles, better together

Hello, and welcome to this technical breakout session. My name is Frederic Courtois, and I am Solutions Architect for One Identity. I work in the pre-sales department. I will talk to you in this session about Active Roles and ServiceNow and the different scenarios that we can implement to have the both product working together and to take the best advantage of both products, which will make them better together. ServiceNow is a ITSM tool, which is highly customizable and in which you can implement lots of different scenarios from the end user perspective to asset management and all different features. The business goal of ServiceNow is to improve operational efficiency by providing end user with a single corporate portal to request compliant access to IT assets. This sentence covers at least two topics which are very important for us and very important for our customers. The first one is about efficiency. And efficiency is a goal for everybody to give the right access to the right people at the right time-- so to save time, to save money, and to have more compliance. And to achieve that agility is very important. But the other aspect of that sentence is that the request compliant access to IT assets, it means that security is involved also in giving the access to the different assets, and the end user will have only the access if it has been approved. The other goal of ServiceNow is to provide single corporate portal to have a unique application for the end users to request access, to open service tickets, to ask for anything in the company. So that's how it is very important for that solution to be integrated to all other provisioning, all other security management aspects. ServiceNow has lots of features about implementing IT workflows, employee workflows, customer workflows. It has a very easy-to-design workflow engine, provides very rich data model with IT management features, operations management, business items, asset management. It has lots of pretty fine features. But it's still missing all the technical bits to manage the provisioning on the different platforms, especially when it comes to manage and automate tasks on Microsoft environments, such as Active Directory, Azure Active Directory, Office 365, and all the related applications. That's why I will talk to you about integration of Active Roles and ServiceNow. As you know, Active Roles is a champion for Active Directory account lifecycle management. It has lots of great features to enable you to automate provisioning tasks, updating tasks, and provisioning tasks in Active Directory, but also Azure AD and Office 365. It is very easy to use and to implement those polices. So the goal of the integration is to enable ServiceNow to interact with Active Roles, and then make a profit of all those automation that you are already implementing in Active Roles. To achieve that, we have lots of ways to interact with ServiceNow. We have lots of protocols and connectors to enable a connection between the two platforms. Active Roles is an on-prem product. ServiceNow is SAS products. And to enable communication between those two products we have different ways. ServiceNow can be initiator of the request to manage the different objects, like user account groups, group membership, assets, tickets, et cetera. But Active Roles can also initiate some connections and some management tasks into ServiceNow. It can also trigger some workflow in one way or in the other. The first is to provision account in ServiceNow. Maybe there are different scenarios for that. For us, ServiceNow can be seen as a target system, and it can be used with all the synchronization capabilities of Active Roles. We provide different scenarios to be able to synchronize information to or from ServiceNow to achieve account lifecycle management in ServiceNow as target. So ServiceNow will be configured as a target of the Active Roles synchronization process. When you create an account with Active roles, it can automatically create the account on the ServiceNow platform. We have several ways to achieve that. The first one is to use the Starling connector for ServiceNow. It is a very easy and straightforward configuration. In Active Roles, you can define a policy to create just the account on ServiceNow based on all the attributes that we will push to ServiceNow. And on the right side, you can see the screenshot of ServiceNow connector platform. You will decide which attribute you want to provide, and it will automatically push all that information to ServiceNow API. By the way, it will create the account on ServiceNow. But we have also another way to synchronize information with ServiceNow, which is the synchronization service connector of Active Roles. We have an on-prem connector to synchronize information, so you can define the workflows to push information to ServiceNow from Active Roles or we can also gather information from ServiceNow to put inactive roles and automate action with Active Roles. You can also manage different objectives from ServiceNow, not only the user of all the groups, but you can also have access to assets and group memberships. You have access to all this schema from ServiceNow, all the attributes which have been created, whether they are default attributes or if they are also custom attributes created in your ServiceNow tenant. Based on that, you can define all the workflows and all the automation, trigger some creation, updation, or the provisioning for different object types. These are synchronization capabilities between Active Roles and ServiceNow, but we also have more integration capabilities, as I will show you now. The first one is a case where ServiceNow is initiating a request. People are initiating from the self-service portal of ServiceNow, will request an item, and then that item will be triggering different action in ServiceNow. But then she can also include an approval workflow or different management tasks before going to Active Roles. The idea is to have a very fluid experience for the end user and having the account ready very, very fast. Again, we use the ServiceNow self self-service portal to initiate the action, then all the processes and policies and all the automations that Active Roles can do will be triggered by ServiceNow through a web service. And how we can do that today is leverage the web service of Active Roles, which is the SPML provider. So we will define some SOAP messages in ServiceNow to call the Active Roles API, then, to give instruction to Active Roles to create the accounts in AD, Azure AD assign a license, and define all the default user profile of those environments. So it can also automate the group management for the Active Directory and Azure groups. It will also assign the account in the proper OU and configure all the different attributes in Active Roles for the account to be enabled. Potentially, Active Roles can also go back to ServiceNow once everything is created, to update a ticket number or the status of the ticket. That is very important to have both products work together to have a fulfilled query. The other way so that Active Roles can also call the REST API of ServiceNow from its internal processes, we have the ability to run scripts into Active Roles during workflow process, during the policy's [? negation. ?] So each time, when needed, we can also call the ServiceNow API to update information, to gather information. Here the example is user creation, but it can also be query, some attributes, some information in ServiceNow, or validate the [? unity ?] of an attribute that we will generate automatically or having a different process that we can [INAUDIBLE]. It can be also a mixed scenario where you have ServiceNow calling Active Roles to create the account, then Active Roles having a script to update the ticket number or the ticket status into ServiceNow. It's a good example of a full request fulfilled by both products. Now I will show you a demonstration of what we implemented in some labs with developers instance of ServiceNow, starting from the end user requesting to have the account created into Active Directory Azure AD and license assign in Office 365. So far of this demonstration, we are using developers instance of ServiceNow, which is integrated with Active Roles hosted in our environments. We are simulating a request to create a new user in the self-service portal in ServiceNow. And the first thing is that we have to request something. When requesting something, we have access to this service catalog and all the different objects. Here we will request the Active Directory and Asia AD accounts for a new user. And I will have to fill only the required fields to be able to create that user and assign him a specific profile based on all the automations that we will execute. So here are the minimum required information to create an account for that user. So we fill the first name. We fill the last name. And we assign that user a specific department. Here it will be finance. Once assigned as finance, it will be pushed through Active Roles. Active roles will use those values to configure the user account and assign the different accesses in Active Directory and Azure AD. So once submitted, ServiceNow has automatically approved the task. Some other scenarios-- we can include an approval task or calculation of different policies that may include other processing in the line. But here, it's just a simple auto-approved workflow. So what's done in the background is, if we go to Active Roles, if you remember, we assigned the user Frederic to the finance organization. And if we go to finance, OU account has been created here on the proper OU, on the proper tree. We know that it has been created by-- here was the system administrator of ServiceNow. And if we go to see the configuration of the user, we can see that it has been automatically added to the proper group department. We can check the different attributes created for that user. We can see so what we type-- the first name, the last name. Display name has been automatically generated. Description was also inserted. Account options. UPN summit name has been generated. In that example, we created the account disabled. We set a random password for that user. And then the user is assigned to the finance department. To achieve that, Active Roles has several policies enabled. We have provisioning policies to generate the different attributes to assign the security groups. And we also have a workflow policy to move the user into the proper OU to be able to configure all the account options and send some notification about the account creation to the manager of the user. This example was about user creation from ServiceNow to Active Roles, but we also have other SOAP functions that we created. Other group interactive directory from the ServiceNow self-service portal, we can also request a group and create a group. Same thing for group membership. People can request to be member of specific groups. So all those functions are quite easy to implement and to enhance. We saw that the default ones-- here we can see that we just provide a group name, some account name, and the place where we create that group. Then it will be automatically also configured, moved, assigned a manager by Active Roles workflows on policies. And the same for group membership. We can expose that group to be requested by a user. So by the different workflows in ServiceNow, you can request approval to different people. Then once granted, we can give the order to Active Roles to add the people to the group, whether it's an on-prem group, a hybrid group, or an Azure-only group. So now, how did this work in an integration perspective from ServiceNow to Active Roles? The first thing is to install the SPML provider on the Active Roles machine, which is basically a web service interface. If you are not familiar with it, you can have access to it via a specific URL here-- the ARSPML website on the books where it is installed. It will automatically talk to the Active Roles administration service. This SPML provider will allow you to add some interaction between a web service and Active Roles itself. We have several actions by default, which are integrated, and we can work with lots of object classes, not only users, but can be user groups and all other-- even computer-- or all other resources in Active Directory. For example, if we want to drill down in that provider, we have all the SOAP requests that we can use. You just have to copy the text to include some attributes-- which type of object you will be managing and then all the attributes that you want to apply. And it will create the request and would push that to the Active Roles administration service, so it will create the user or put the query exactly as if it was done from the synchronization service or from the web interface. And you can also, from this test, that SPML provider is quite powerful to integrate activities from outside. This is the first prerequisite, then make sure ServiceNow has access to this interface. Now, from a ServiceNow perspective, we had to create several objects. Not that much, and not too complicated. But the first thing is we created the catalog item. So the Azure Active Directory accounts that we display in the self-service and you define, description, and all the icons that we use on the web interface. Then we point to a specific variable set, which is a grouping of the different attributes that we are using in the web form, but also potentially other information that are calculated just for the general object management tasks. So once we have that query, we just have to define a workflow, make rules, and define how ServiceNow we handle that query. It will be triggered by a business rule, simply to enable the user creation and to push the different attributes in the SOAP message that will be sent to the Active Roles web service. So it's a simple script, which will gather the different attributes from the web form, then change, potentially, the display value or calculate some attributes, and then push that to a specific object which is a SOAP message. The SOAP message is gathered from the WSDL file in the SPML web interface. And then we created some specific functions in that, like the new user here. It's called add user in our example. We see here the same syntax that we saw on the web interface for the SPML provider, and we push on that SOAP query the object class user. We create the user by default in the from ServiceNow OU, which is the temporary OU that we use to create new users with ServiceNow. Then the workflows and the policies in Active Roles will analyze that user and move it and configure it as we want in Active Directory, Azure AD, and Office 365. So we create the user on that specific OU, and then we generate the different attributes. We saw the description here, the common name, some account name. And the department, first name, last name were provided also from the web form. And once all that information is pushed to the SOAP endpoints, Active roles have information, and then it will automatically create that user first was created in the from ServiceNow OU. And it has been moved in the proper OU and as I assign him to the finance departments, it was moved to the finance OU and assigned to the finance security group. So that's the basic configuration for the user, but it shows how Active Roles can get information from ServiceNow and then continue to configure more deeply the user for the Microsoft alignment, AD. I can also create the pending Azure AD account and assign a default Office 365 license, which are very basic Active Roles provisioning policies. So now if we come back to the slides, I've gathered several information for you as a reference, if you want to have them in the slides. So we created that application in ServiceNow, which we call Active Roles Add On for ServiceNow in which we can see all the different objects. So the business rules to provision the user into Active Roles, the business rule to create the user from the search service. We are using the different viable sets-- the catalog item and the workflow. So the idea is to trigger the requests by requesting the object from the web interface, then executing the workflow. So that workflow is starting by an approval request. Be sure that we really need to create that account in Active Directory. In the live example I just showed, it was automatically approved, so we had no steps to approve. But here, that example of workflow is a more complex one. Then we called the API and sent a SOAP message via the script table here. And then the user was created. It creates the call to the SOAP message. And the SOAP message, as we saw before, is completely customized by how we want the user to be created in Active Roles. Then Active roles creates a user, applies the policy to workflows and updates the ticket status via a script who is calling the ServiceNow API. OK, so I hope that demonstration of integration capabilities between ServiceNow and Active Roles was interesting for you and very useful. We have lots of scenarios that we can include in that kind of automation, starting with the different. And again, it's one example among all what we can do as integration between ServiceNow and Active Roles. We can create as many workflows, as many use cases, as needed for fulfilling your needs. Please, don't hesitate to ask us or to call us to have more details about those integration scenarios. Thank you very much, and have a nice evening.