Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to use Sharepoint+SCO to achieve PAM portal, the article is very detailed, has a certain reference value, interested friends must read it!

In practical enterprise applications, what enterprises want is not only through artificial examination and approval + manual operation of Powershell, it is better to have a portal where users can apply for permission and approve through online workflow, and the bottom layer is supported by PAM technical tools, which is closer to the actual environment and easy to review. In this advanced article, we will make the operation part and report part of PAM into a portal to achieve three functions.

Users apply for timeliness permissions in the portal, are approved by the administrator, and automatically join the local domain security group or security principal

After the application is successful, the user's application and approval information will be automatically filed into a report.

Support permission recovery for user application records on the portal, change the recycling field, and automatically reclaim security group or security principal permissions at the background.

As far as Microsoft's product system is concerned, there are three options for JIT JEA security agent technology at the bottom of PAM to realize portal application, examination and approval, and filing, Sharepoint+SCO,SCO+SCSM,MIM2016.

In this article, we will mainly focus on Sharepoint+SCO to achieve PAM portal, Sharepoint+SCO+PAM three parts of process docking, thinking guidance, for the concept of PAM, the principle of PAM technical tools, PAM technology configuration, this article will not repeat.

The role of each component in the process is as follows

Sharepoint: create application list, audit report list, and the administrator defines the information that needs to be entered. You need to note that the information in the application list should include three basic information: application domain account, target application group, application time, and so on. These three information will be monitored by SCO, and SCO will use these three information to allow AD domain to join security group or security principal. In addition, Sharepoint needs to implement the approval workflow, which is used as a follow-up confirmation item for each record. The user's application must be examined and approved artificially in Sharepoint first. After the approval is approved, the workflow status of the application record becomes approved.

SCO: for Sharepoint, the workflow is over, but for the next station SCO, the workflow has just begun. SCO captures the approved project, passes the data of the passed project to the next station through databus to execute the script, executes the script activity, takes the information entered by the user, connects to the domain control service to join the security group or joins the security principal.

You can see that in the whole process, Sharepoint mainly acts as the input, approval, display and storage side of the application. What SCO is doing is to dock the information of Sharepoint with PAM, and directly let the result of Sharepoint input be executed in AD domain, so that the information entered by Sharepoint changes from static to real effect.

For the product of SCO, Lao Wang will give a brief introduction here. SCO, whose full name is System Center Orchestrator, is an automation product in Microsoft's System Center2012 suite and its main functions

Support Microsoft's self-service implementation of private cloud, dock SCSM and underlying VMM, transfer users' SCSM self-service applications to VMM creation and take effect.

Support hybrid cloud scenarios, support for integration of resource requests with Azure IAAS, and integration of hybrid automation calls with Azure SMA.

Coordinate automated collaboration between different components or systems within the data center or between different systems.

Administrators can design automated collaboration processes by dragging and dropping to lower the threshold of automation.

SCO product installation components

Management Server: responsible for the connection between SCO and database, the integration package imported by the user and the written runbook will be stored in the SCO database. SCO will go to the database through Management Server to retrieve runbook and integrate the package data.

Runbook Server: responsible for the actual implementation of Runbook

After the Orchestrator Console and Web service:SCO is installed, there will be a Web console for the web page to view and execute the runbook. The default port 82 is for SCSM or other web programs to call runbook. The default port is 81.

The visual designer of Runbook Designer:Runbook is only responsible for process design, and the real execution of the process is in Runbook Server

Each component can be installed to different servers, each component supports multiple deployments, and each Runbook supports specifying different Runbook Server execution

SCO system service

Orchestrator Management Service:Managment Server role service, which is responsible for receiving runbook server requests to retrieve data from the database

Orchestrator Runbook Service:Runbook Server role service, responsible for executing the runbook activity process

Orchestrator Runbook Server Monitor: Runbook Server role service, monitoring Runbook execution status and events

Orchestrator Remoting Service:Deployment Manager remote deployment IP uses

Introduction to SCO terminology

Runbook: describes an automated process designed by Orchestrator. A Runbook can be composed of multiple activities, connecting multiple activities to form an automated process.

IP:Intergration Pack, by default, Runbook can only be based on the default existing activity design process. You can import different product IP to make SCO have more activities and complete the design of Runbook.

Deployment Manager: used to deploy IP packages, each IP package needs to be deployed to the Runbook Designer for the design and to the Runbook Server for execution

Databus: when we connect multiple activities together through a cable in runbook, the data monitored by the previous activity or the data generated after execution will be transferred to the next activity through databus. In the next activity, we can subscribe to the published data and use the data generated by the previous activity to complete the next automation activity. A single activity does not have the concept of databus, and when multiple activities are connected by a cable, the databus will be passed in each subsequent activity.

Connection line: connect multiple activities to form a process by dragging. The connection line can be passed to different activities according to different results. For example, the previous operation was successfully passed to the next activity A, and the execution failure was passed to the next activity B. you can customize the connector label to remind the administrator of the use, and you can customize how long the last activity is delayed before executing the next activity. The connecting line is the bridge to build databus.

Check in and check out: when we create a new runbook, it will be checked out by default. After runbook tester testing, we check in the runbook, and then we can run runbook to make the runbook take effect. A running runbook cannot be directly modified. You need to stop the runbook, check out the runbook, and check in the runbook after the modification is completed. The modified content will only take effect.

For this process, the most important thing is to understand the concept of databus in SCO. We need to establish a runbook process and let the runbook process monitor the data filled in by sharepoint. After monitoring that the workflow has passed, the data is passed to the next activity through databus. Whether the domain is added to the timeliness group or added to the security body of the fortress forest, it is executed through script. So the next activity of monitoring sharepoint activity must be followed by the activity of executing script. We should pass the data monitored by monitoring sharepoint activity to the activity of executing script, and the final script is actually the input data of sharepoint.

The following will begin to carry on the actual process design and demonstration, to help you strengthen your understanding through experiments. Due to the limited space, we will not demonstrate the installation of SCO,Sharepoint, as well as the basic configuration, such as list creation, integration package import, etc., we will gradually achieve the three functions of the goal. First of all, we will achieve the implementation of the three functions of the PAM portal in the scenario of membership of a single domain timeliness group.

At present, ABC has upgraded the domain control to 2016, the forest domain function level to 2016, and enabled the PAM function. The privilege management group has been combed and prepared, leaving only the necessary function administrator, and the personal administrator has been cleared. Now we hope to realize the online request, approval, archiving and recycling of the timeliness membership of the personal administrator through the portal.

Introduction of experimental environment

PRIVDC 2016 domain control virtual machine 1VCPU 2GB memory

Sharepoint 2013 + SCO 2012R2 virtual machine 4VCPU 8GB memory

Function 1: to enable users to apply for timely permissions in the portal, approved by the administrator, and automatically join the local domain security group or security principal

Preparation: Sharepoint creates a custom list of permission applications. In addition to the required domain account, target group and limitation of application, the administrator can design the required columns by himself.

The domain account applied for is the name of the domain account that will eventually be added to the privilege group.

The application target group is the name of the privileged group to which you actually want to join.

The application time is passed to the TTL when the script is executed later, which can be designed as days, hours, minutes and seconds. Here I design it as minutes, and then the script also designs TTL as minutes.

Applicant information can be modified directly by using the list with its own creator.

Turn on the workflow function in the site collection function, then create an approval workflow in the list Settings Workflow Settings, and check the new project at the startup option to start this workflow.

To configure the workflow approver, you can plan a security group as the assigned object. In the experiment, I specify that it is approved by Stat every time.

In this function, what we need to do by Sharepoint is already in place, provide the Web application form, provide online workflow approval, and then it is the performance time of SCO. Before the opening, don't forget to import AD and Sharepoint IP packages for SCO Runbook Server and Designer servers. Remember to configure each IP package at the options above the Designer interface after import, such as the domain to which the AD package connects to and the collection of websites to which Sharepoint is connected.

The first pit will be encountered here, it is important to note that there is a Default Monitor Interval Seconds property in the configuration sharepoint connection, which is the default interval for sharepoint activities to poll and monitor sharepoint data. All sharepoint activities will inherit this setting. The default is 15 seconds. You must be smart to shorten it. After shortening it, you will find that sharepoint automation activities have failed.

In order to achieve this function, ah, it is not that easy, and we also need the support of SCO activities. Imagine that we have two prerequisites to pass on to the next activity.

Pass each newly created record that has been approved by the workflow in sharepoint

Pass the record that the approval failed after the new creation, but has been approved after a period of time.

From the design point of view, this is a reasonable requirement, but from the implementation point of view, it is not so easy. If SCO wants to monitor a specific txt, a specific log is OK, but it is a bit difficult to monitor each update. Fortunately, the Monitor List items activities in version 7.2 of sharepoint ip perfectly support our requirements, you can monitor new records and monitor change records. And can be designed to meet the screening criteria to receive data.

Drag and drop the Monitor List items activity into the design panel, select the list of applications to be monitored, make sure that the Monitor Interval Seconds is 15 seconds or more, Monitor New items is true, monitor the new project, Monitor Modifieds items is true, and monitor the change project.

The approval field of the design screening process in Filters is passed to achieve the effect. When a new application is connected, this data will be monitored only when the SharePoint workflow has been completed and the approval status has been passed, and the monitored data will be transferred to the next activity on the SCO databus. In addition to the new, the change is the same. Suppose we create a new record in sharepoint, but the approver does not approve it in time, and the status of the process approval field will be in progress. At this time, the record will not flow through SCO databus to the next activity. After a while, the approver approves the record, and the record becomes passed. Monitor List Items will also be aware of the modification when the Monitor Interval Seconds time arrives. Flow the data modified to passed to the next activity through databus.

Add the activity of running .NET script, select Powershell as the language type

At the Monitor List Items activity, draw the connection line, connect to the next activity, and establish the databus flow

Copy this script in a script activity

$session = New-PSSession-Computer PRIVDC

Invoke-Command-session $session-ScriptBlock {

Import-Module ActiveDirectory

$TTL = New-TimeSpan-Minutes 10

Add-ADGroupMember-Identity "Domain Admins"-Members "Tony"-MemberTimeToLive $TTL

}

The next interesting thing is that we are going to pass the input data in sharepoint through databus to the script to AD for execution.

At the script, click-Minutes to delete the number 10, right-click, select subscribe-published data, and look for data from databus

Choose the minutes ttl time here. Instead of using static, use the application time value passed from the previous activity.

Replace the application target group in turn, and the application domain account data is the value sent by sharepoint.

This is the magic of SCO, it can transfer data between different systems, your former activity system is sharepoint, the latter activity system is AD domain, it doesn't matter, I can also pass to the next activity through databus, as long as the data you pass does not violate the format type needed for the next activity execution.

Some people here will encounter a second hole, which is a problem at the script level. It turns out that when we execute a command, there will be a space after the-Identity command, followed by a domain admins static group, but when we replace it with data from sharepoint, there will be a space missing after-identity, so we will encounter the failure of this activity execution.

Also, the latter parameter also has this problem. There is originally a space in front of the TTL parameter, and the front is a static user who wants to join the time qualification group, but after we replace it with the application domain user in sharepoint, this space will disappear.

So it will cause the execution of the .NET script to fail. You can take out the script passed by SCO after sharepoint and copy it to ISE. You can see that the problem can be solved by going back to SCO to deal with the spaces in these two places.

So far, the first function, SCO and Sharepoint, has been partially configured. Let's verify the function.

User eric is an ordinary user. Log in to the sharepoint portal to apply for a 5-minute domain admins group qualification.

The application is approved by stat in time, and the process approval is updated to passed. SCO Monitor List Items perceives that the new project is established, monitoring is successful, and the next activity is triggered. You can see the execution record of Runbook below.

By viewing the limited membership of the administrators group, you can see that the TTL limitation qualification of Eric has taken effect.

Get-ADGroup-Identity "Domain Admins"-Properties *-ShowMemberTimeToLive | fl member

The current Jack user has submitted an application, but has not been approved by stat in time. If the approval status is in progress, the SCO activity will not be triggered.

After a period of time, stat approved jack's request, and the status was updated to approved.

SCO Monitor List Items perceives that the project has been updated, the monitoring is successful, and the data is passed to the next activity execution script, which can be viewed in the log history.

Looking at the command, you can see that Jack has also obtained the timeliness membership group.

At this point, we have completed the implementation of the first application function, the user does not know what is happening in the background, they will only see the permission take effect after the approval is passed, only we know, in fact, we are combined with Sharepoint+SCO to achieve something cool, if the enterprise has an Exchange server, you can also add an activity, when the script activity is executed successfully, the email notifies the user that the user has been granted temporary permissions.

Next is the second audit function. A major part of PAM is to record the application for privilege, including the applicant, the reason for the application, the privilege group, the approver, the effective time of the privilege, and so on, to form a visual audit report. The role of Sharepoint is to provide the audit list automatically filled in by SCO. Lao Wang designed the information column needed for audit in sharepoint, for reference only.

In the SCO part, for the audit function, our design idea is to add the third activity to create the list project, and let SCO automatically get the data of the Monitor list items activity. When the second script is executed successfully, it automatically fills in the data of the first activity to create the list project. Since the third activity to create the project needs to use the data of the first activity, we need to make sure that all three activities are connected to the connection line. On the same databus, that is to say, when an application is approved in sharepoint, it takes three activities to enter SCO. Get data 2. Pass it to AD to execute script 3. The audit data is created based on the obtained data, and the process ends after the successful execution of three activities.

Drag and drop the Create List items activity into the design panel

Subscribe to data and choose to subscribe to published data from the first activity

Fill in the data from the first activity in turn, and there is a privilege effective time. Lao Wang suggests that you can obtain it from the second activity that runs the script, and this value is taken as the successful end time of the second activity. After this time, ordinary users must have joined the privilege group, so taking this automatic time must be the most accurate. This is also a benefit achieved through automation, avoiding a lot of artificial memory deviations.

As to whether the permission is reclaimed, Lao Wang has made a list of options in sharepoint. The default setting is not reclaimed.

The process is now set up as follows

This function has been designed and completed here, so let's verify the function.

User mike submits an application request in the application list

Stat approval passed, process approval status changed to approved

The SCO activity monitors the matching data and starts to trigger the activity. The three-step activity is executed successfully.

Check that Mike has obtained the privileged group permission within the prescription permission.

Open the created audit list of IT permissions, and you can see that the audit information automatically created by SCO automatically takes the data of the first and second activities.

The third function: support the permission recovery of the user application record on the portal, the user changes the recycling field, and the background automatically reclaims the security group or security principal rights.

As you can see, in the second function, we have designed a column on whether permissions are reclaimed, which Lao Wang thinks is also necessary for audit information. if it is not automated, then the auditor needs to confirm with the approver whether the permission is reclaimed, and then update the record. With the automated process, we can implement the auditor or IT manager to view the permission audit list. If you think that a certain permission should be reclaimed, you only need to change whether the field of permission recovery is recycled. The backend SCO detects the change, triggers a command to remove the user from the security group or security principal, removes the user's permissions, and then updates whether the list permissions are recycled. The update permission reclaim time is the time the user is removed from the security group or security principal.

This feature is not only applicable to the audit records that we have automatically updated through the timeliness qualifications created by our application, but also the IT administrator of the enterprise can register the manually assigned permissions here to check regularly whether it has been reclaimed and whether it needs to be reclaimed, and complete it automatically if necessary.

To implement this, we need to do another runbook process separately, because two monitoring list activities cannot be done in the same runbook. This runbook is used to monitor the audit list of IT permissions, monitor whether the filter permissions are recycled fields, and then pass the data to the next activity execution script. When the script executes successfully, the recovery status is updated to be recycled.

Create a new runbook, add monitor list items activities, and choose to monitor the audit list of IT permissions this time.

Set Filters to only collect and pass permission to reclaim data that is equal to the data that needs to be reclaimed.

Add the activity of running .NET script to replace the group that was statically deleted with the published data application privilege group. This value comes from the audit list, which is generated only if the permission has been granted, so there must be no mistake.

$session = New-PSSession-Computer PRIVDC

Invoke-Command-session $session-ScriptBlock {

Import-Module ActiveDirectory

$ConfirmPreference = 'none'

Remove-AdGroupMember "Domain Admins"-Members Jack

}

The member to be removed is replaced by the audit list permission applicant, that is, the application domain account entered at the time of the application, who is actually added to the privilege group.

If the script fails, don't forget to check the spaces and don't lose the last} that ends with-ScriptBlock.

Add a third activity, update list item, and select the project to update: permission reclaim status, permission reclaim time.

Whether the permission is reclaimed or updated to be recycled. You can run the .NET script from the second activity to get the end time of the activity. You need to check the value below to show commonly published data before it is visible.

The ID needs to subscribe from the first activity, which is the ID of the piece of data that met the criteria and passed to the second activity.

All three functions have been designed and completed here. Finally, we will verify the overall function.

Jack is currently a temporary account created for outsourcers. Jack needs to take this account to inspect the server and temporarily apply for one hour's domain admins permission.

After the Jack submits the application, Party A manages the stat approval. After the approval is passed, the approval status of the process is updated to passed, and the SCO captures the data and passes it to the following activities for execution.

After the successful execution of the process, verify that the account has been granted temporary permissions

At the same time, the data of the account is written to the audit list, whether the permission is reclaimed as unrecycled, and the permission recovery time is empty.

The outsourced personnel inform Party A that the inspection has been completed and the authority can be reclaimed, and Party A's personnel can set the authority to need recovery.

The second Runbook process captures the incoming data that needs to be collected and passes the monitored data to the next script activity, which removes the user from the AD group.

Whether the third activity update permission is recycled, and update the permission recovery time.

So far, we have fully implemented all the planned PAM portal functions. We can see that Sharepoint SCO PAM technology works well together, and the three components depend on each other to achieve the final available solution. In the whole functional system, administrators need to be clear at all times about the relationship between this process operation and the next process, so as to cultivate their own ability to understand the cooperation between multiple systems. For example, the data input by sharepoint is transmitted to SCO. The final AD domain executes, and if the sharepoint list updates the column name, it needs to be refreshed in SCO, and SCO needs to ensure that the data can be passed to AD for correct execution.

The biggest advantage of using sharepoint as a portal is that we can get flexibility. We can customize the column information we need, and we can customize the workflow in sharepoint. We do not need to face complex MIM portal deployment or complex SCSM service directory stack, but only need to maintain an additional SCO. Through Sharepoint+SCO+N, the requirements of many scenarios can be realized, because the docking of SCO and sharepoint is good, and the process does not need to be too complex to transfer data to other systems for execution. It is strongly recommended that administrators learn about sharepoint, understand sco, realize cross-system automation processes in their own enterprises, and show their value.

In fact, PAM is not the only concept put forward by Microsoft. It is recognized as a major topic in the security industry. Lao Wang believes that enterprises can be divided into five stages in the PAM process.

Understand the concept of PAM, recognize the importance, and recognize the need to do PAM

Start to plan PAM in the enterprise, put the technology and administrative means in parallel, for example, the privileged account must meet the password complexity requirements, establish the member registration form of the administrator group, the privileged account must change the password after the user leaves, the privileged account must be isolated from the service account, and the temporary account must not be used for the application system account when signing the project with the outsourcing personnel. the temporarily assigned management account will be disabled. Outsourcing personnel are required to standardize the use of service accounts and management accounts, identify permission applications, temporarily grant temporary permissions by mail, etc., and the arrival deadline must be deleted. Minimize permissions for applications as far as possible.

Understand the concepts of PAM tools and technologies, such as Microsoft AD2016 JIT and JEA, and start to sort out the first administrators in the environment. The privileged group only retains the key function accounts, the password is highly secure, and the remaining individual management accounts release the privileged group, and begin to grant trial through powershell+ manual operation.

Landing PAM application, using sharepoint+sco or sco+scsm or mim2016 or self-developed Web system to build permission application, authority audit portal, for the use of privileged rights, must go through the application, approval, archival audit, must be able to operate and recover, so as to achieve the operation-audit model of PAM. For privileged account protection, if MIM is used as the security portal. It can be designed to be authenticated by Azure MFA when the user applies for permission, or by Azure MFA or smart card when the user logs in to sharepoint if sharepoint is used. For important servers, the administrator workstation installs anti-virus software to prevent software theft.

Separate the management from the application, thoroughly separate the user's personal management account from the existing production forest, build a separate fortress forest, use it to store the management account, and then go through the portal for approval when it is necessary to perform privileged access, thus reducing the risk of production forest management account being cracked and horizontal attack.

After the article Microsoft privileged access Management was issued, some netizens and Lao Wang discussed that with regard to the application of Fortress Forest in China, it is undeniable that this is indeed a big fight. It is necessary to sort out the management account. There is no management account in the production forest, which is not an easy task. We must check each system well and confirm that it is not used before removing it. But whether it is worth thinking about whether it is worth considering the level of security that enterprises need.

My netizens and I discussed a very interesting example. We call the current integrated architecture of single forest and single domain application and management account all-Naruto architecture, and every administrator is Naruto. Then a malicious administrator can blend into a ninja high-level as long as he has mastered the characteristics of a ninja. The time-limited access qualification is for some temporary tasks, which are approved by the shadow and then temporarily become the right to become the film. The structure of the fortress forest is that, except for the village head and several indispensable shadows, all the other shadows are taken out separately to become villagers, usually without any contact with Naruto, when it is necessary to carry out the mission, temporarily apply to become a ninja (join the security subject), and re-become ordinary villagers who have nothing to do with ninjas at the end of the mission.

I don't know if you understand that the so-called fortress forest architecture is actually to compress the cracking space of hacker. Originally, you could scan 100 administrators in the production forest, but now there are only five in my production forest, and they all have high permissions. Identity protection is enabled. When performing management operations, ordinary users of Fortress Forest will apply to join the security principal that has been created. When the administrative operation is completed, the fortress forest user becomes a normal permission. The original 100 administrators have now become the security subject of the fortress forest, and the fortress forest users will be temporarily penetrated and executed when needed. The production forest cannot see these fortress forest user members, and there is no point in cracking the fortress forest users, because the fortress forest users are ordinary permissions every day, and it is not necessary for the fortress forest user to apply for the security subject every time.

MS sometimes says that the fifth stage is called PAM, but Lao Wang thinks that it may not be so. Whether an enterprise wants to introduce PAM,PAM successfully or not depends on whether administrative means and technical means finally take effect, and to what extent internal managers follow the rules of PAM to complete the acquisition, application, examination and approval, use, recording, manipulation, and the extent to which the life cycle of privileged accounts is secure and controllable.

In view of the future of Microsoft PAM, Lao Wang hopes that in the next step, Microsoft will be able to control that administrators who are qualified for JIT can only perform management operations on a limited number of servers, and that they can automatically turn off remote dial-in and mailbox functions after recovering their rights, reduce the deployment complexity of their own MIM portal, and simplify the JEA setup steps to allow configuration files to be updated in real time.

Finally, as a colored egg, we will practice the fifth stage of fortress forest, how to use Sharepoint+SCO to realize the main role of portal request shadow under the framework of production forest.

To apply for a shadow subject, we need to change the list of the Fortress Forest Sharepoint to change the application target group into the target subject role, which can be made into an option menu, where the content of the menu needs to be the shadow subject that has been created in the Fortress Forest. Here I add Domain admins,Enterprise admins and the Automation admins role defined by JEA.

The list of applications for modifying IT permissions is as follows

To make the Runbook process, the first activity is to monitor the Sharepoint list. The project approved by the monitoring process is passed to the next activity through databus.

The second activity is also to run the .NET script and copy the script into it.

$session = New-PSSession-Computer PRIVDC

Invoke-Command-session $session-ScriptBlock {

Import-Module ActiveDirectory

Set-ADObject-Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com"-Add @ {'member'= ""}

}

Replace three places: 1.CNSecretABC-Target subject role 2.TTL = Application time seconds 3.CNC = Fortress Forest account

I believe that friends who have read the whole article should know what Lao Wang is talking about here, so I will no longer send out picture instructions, but should pay attention to the space problem and the last} problem.

User Mike of Fortress Forest logs in to Fortress Forest Sharepoint to submit an application for the permission of the target subject.

After the Stat approval is approved, the Runbook captures the data and passes it to the next activity, which is executed according to the pre-set cross-system mapping.

When you open the shadow body of Fortress Forest, you can see that the mike user is already a member of the domain admins shadow body of the production forest. At this time, the user mike of Fortress Forest has the permission of the production forest domain admins group through the shadow body, and can log in to the production forest server, but will automatically remove the shadow principal member when the timeliness arrives, or do a second runbook to support the administrator portal operation to remove the permission. As a result, Sharepoint+SCO can not only apply for timeliness group qualification in its own domain, but also apply for cross-forest shadow subject of fortress forest framework.

The above is all the content of the article "how to use Sharepoint+SCO to implement PAM Portal". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.