Running Discovery against LINUX devices that have been set up using the PAM module for access

[Leon Blackman]

Has anyone come across the situation where they need to set up Discovery in an environment that uses a local PAM module for authentication which requires a Yubikey OTP for authentication. 

This is implemented via a local PAM module and applies system wide. This means that SSH connection with a passkey will not work.  Can I use a target connector to let PAM communicate with S/N and will this then allow the Discovery probes to run?

[Matthew_13 · Accepted solution]

Hi Buddy,

Yes — this comes up more often than you’d think, and unfortunately the answer usually isnt what people hope for.

Discovery cant handle any kind of interactive authentication, including PAM setups that require a YubiKey OTP. Discovery runs completely non-interactive. If PAM is enforcing OTP system-wide SSH will fail before Discovery ever gets a chance to run probes.

A target connector won’t help here. Target connectors only control how Discovery talks after a session is established. PAM authentication happens before that so there’s no way for ServiceNow (or the MID Server) to “participate” in the OTP exchange.

Basically :

• Discovery can’t respond to OTP challenges

• PAM can’t “talk to ServiceNow” to approve a login

• YubiKey-enforced SSH blocks Discovery by design

This isn’t a ServiceNow limitation you can script around — its just how secure, non-interactive automation works.

What I have seen people usually do instead:

• Create a dedicated Discovery service account that’s exempt from OTP, but:

  • Locked down to MID Server IPs

  • Key-based auth only

  • Very limited sudo access
    This is the most common and audit approved solution.

• Or, use conditional PAM rules (or a bastion host) so OTP is required for humans but not for machine accounts coming from known MID Server IPs.

• In some cases, reduce reliance on SSH Discovery and use SNMP or API based discovery where possible — but that won’t fully replace OS discovery.

Bottom line:
If PAM requires YubiKey OTP for SSH, Discovery will not work directly and a target connector wont change that. The fix has to be in the PAM policy design, not in ServiceNow.

If you want, tell me what PAM product you’re using Duo, CyberArk, BeyondTrust, pam_yubico etc... and I can help you frame an exception model that security teams usually accept.

@Leon Blackman - Please mark Accepted Solution and Thumbs Up if you found Helpful 🙂