banshee est en développement actif : les collecteurs vont encore changer, et une version que vous publiez demandera sans doute des ajustements. Pour un usage stable, attendez la version 1.0.0.

Active Directory

banshee/active-directory-collection/active-directory/ssh/

fsmo

The holder of each of the five FSMO roles and whether it answers on the LDAP port, by SSH and PowerShell

  • active-directory
  • domain-controller
  • fsmo
  • ssh
  • powershell

par banshee1 installation2 versions

v2Dernière

Publiée le 28 octobre 2026. One naming convention across collections; documentation completed.

FSMO roles, by SSH

Returns, for each of the five FSMO roles, the domain controller that holds it, as the monitored domain controller knows it, and whether that holder accepts a connection on the LDAP port from the monitored domain controller. One watch is proposed, checked: a holder that does not answer.

Versions

A domain controller running Windows Server 2012 or later, with Windows PowerShell 3.0 or later, as the prerequisites name them. Generic: no folder of version. That every release answers alike is assumed, not yet checked on a real domain controller.

How it works

The collector runs one PowerShell command that reads the roles through the classes of .NET that Microsoft documents, and opens a TCP connection to each holder:

powershell -NoProfile -NonInteractive -Command "$ErrorActionPreference = 'Stop'; [Console]::OutputEncoding = New-Object System.Text.UTF8Encoding; $computer = Get-CimInstance Win32_ComputerSystem; $server = $computer.DNSHostName + '.' + $computer.Domain; $context = New-Object DirectoryServices.ActiveDirectory.DirectoryContext('DirectoryServer', $server); $dc = [DirectoryServices.ActiveDirectory.DomainController]::GetDomainController($context); $holders = [ordered]@{schema = $dc.Forest.SchemaRoleOwner.Name; 'domain-naming' = $dc.Forest.NamingRoleOwner.Name; pdc = $dc.Domain.PdcRoleOwner.Name; rid = $dc.Domain.RidRoleOwner.Name; infrastructure = $dc.Domain.InfrastructureRoleOwner.Name}; $roles = @(foreach ($role in $holders.Keys) { $reachable = $false; try { $tcp = New-Object Net.Sockets.TcpClient; $reachable = $tcp.BeginConnect($holders[$role], 389, $null, $null).AsyncWaitHandle.WaitOne(3000) -and $tcp.Connected; $tcp.Close() } catch { }; @{role = $role; holder = $holders[$role]; reachable = $reachable} }); ConvertTo-Json -Compress -Depth 4 -InputObject @{roles = $roles}"
  • The monitored domain controller is named by its full DNS name, read in Win32_ComputerSystem (DNSHostName and Domain), and the roles are read on it: DomainController.GetDomainController, then Forest.SchemaRoleOwner, Forest.NamingRoleOwner, Domain.PdcRoleOwner, Domain.RidRoleOwner and Domain.InfrastructureRoleOwner (Microsoft, .NET, System.DirectoryServices.ActiveDirectory).
  • The roles, one instance each: schema (schema master), domain-naming (domain naming master), pdc (PDC emulator), rid (RID master), infrastructure (infrastructure master). The first two belong to the forest, the other three to the domain of the monitored domain controller.
  • A holder is reachable when it accepts a TCP connection on port 389 within 3 seconds; nothing is sent on the connection. A bind with the account is not tried: whether an SSH session can hand its credentials on to another server depends on how it was opened, and a holder would then look refused for a reason of the session. A name that does not resolve counts as unreachable.
  • Fewer than five roles, or an answer that is not the expected JSON, stops the collector as misconfigured, as does a domain controller that the .NET classes cannot reach.

Nothing is written to the Windows or to the directory: the command only reads, and the connections send nothing.

Prerequisites

  • A domain controller running Windows Server 2012 or later, with Windows PowerShell 3.0 or later.
  • The OpenSSH server of Windows, installed and started, its default shell left at cmd.exe, the Windows firewall open to the poller on TCP 22, and the fingerprint of its host key set in protocol:ssh:fingerprint unless the Security settings trust the first SSH fingerprint presented: the steps are those of the windows/ssh/services collector of banshee/windows-collection.
  • An account of the domain for monitoring, without administrator rights, set in protocol:ssh:user, with its password in protocol:ssh:password or its key in protocol:ssh:private-key. No group: the holders of the roles are read in the directory, which any account of the domain reads.
  • TCP 389 open from the monitored domain controller to the other domain controllers, as Active Directory needs it anyway.

Outputs

NameLabelUnitPer instance
holderHolder—yes, per role
reachableReachable—yes, per role: yes or no

Watches

NameTitleKindDefaultsChecked by default
unreachableRole holder unreachablestate to avoid, on reachablecritical on noyes

Limits

  • The holders are those the monitored domain controller knows: one whose replication lags may name a former holder. The replication collector watches the lag.
  • A holder that accepts a connection on port 389 may still fail to serve its role; the test says it is up and reachable, not that the role works.
  • Not yet checked on a real domain controller: the execution; that reading a role owner does not contact its holder (only its name is read); that Win32_ComputerSystem.Domain is the DNS name of the domain on a domain controller; which right lets an account that is not an administrator open an SSH session on a domain controller.