Microsoft Active Directory v2 Spoke RequirementsSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } 1. You may inquire about detailed connectivity (endpoints/protocols/ports) requirements between ServiceNow, MID Server used by Microsoft Active Directory v2 Spoke and Active Directory. First involved here is the Credentials.psm1 script having Powershell as a parent. https://yourinstance.service-now.com/now/nav/ui/classic/params/target/ecc_agent_script_file.do%3Fsys_id%3D3f234355376001006b882d465abe5de8 containing this line: $rootEntry = New-Object System.DirectoryServices.DirectoryEntry "LDAP://$computer", $user, (unprotect $password); The script provided is in global scope. This is triggered after you trigger an AD spoke action, but this is the first level of authentication that the platform undertakes, depending on the credType value specified in PowerShell step of the action. So if you trigger an action that has the credType=AD, see example Enable User actionhttps://yourinstance.service-now.com/$flow-designer.do?sysparm_nostack=true&sysparm_use_polaris=false#/action-designer/ec517a1687fc51107701ed3e0ebb3599/step/2799c440-b463-4826-9160-c83f36d119e4this line $rootEntry = New-Object System.DirectoryServices.DirectoryEntry "LDAP://$computer", $user, (unprotect $password); will trigger fromhttps://yourinstance.service-now.com/nav_to.do?uri=ecc_agent_script_file.do?sys_id=3f234355376001006b882d465abe5de8This is going to authenticate your MID server to the target endpoint depending on the target you specified ( in this case AD).After the authentication piece is completed , only then the code part of the spoke MID server script starts to trigger (ActionEnableUser_AD_v2.ps1).Here the script will be executed on the MID server itself.At this stage you can see line Import-Module ActiveDirectory inhttps://yourinstance.service-now.com/nav_to.do?uri=ecc_agent_script_file.do?sys_id=9227502c1b8d2010dd8e0e16ec4bcb9athis will import the module and allow the script to call any method which is part of this moduleExample: get-ADuser (a cmd-let) In the execution of the action itself which uses PowerShell step , we are using methods/cmd-lets that are part of Module ActiveDirectory.https://learn.microsoft.com/en-us/powershell/module/activedirectory/?view=windowsserver2022-psthe protocol naturally used is ADWS, with OOB port of 9389. As we can note from the above, LDAP is used in the credentials check phase.This is part of credential check and is not part of the AD spoke itself.In this case LDAP port 389 needs to be open ( but you can change it to 636 if needed).Note: If you change the script Credentials.psm1 you need to be cautions during platform upgrade. 2. Regarding the above discussion, it may be confusing why the override default port is available on the form ( see screenshot). This is because the form is used by multiple connection on our platform is using the same form, and this is not aplying to all connections. 3. Another concerns you may have is that the account/credentials used for AD integration are in different domain than the account used for MID (there is no trust between domains ). For this we do recommend that MID and Active Directory are in the same domain. If you wish to keep in different domains, you would need work with your Active Directory Admins and have the trust established between both the domains so that MID can execute the cmd-lets and fetch the details. A good test would be to execute get-aduser cmd-let and pass credential and server parameter from MID server Get-ADUser -Identity $userName -Credential $cred -Server $computer -Properties * -ErrorAction Stop; See more here: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0995390