We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Active Cloud not classify

KranthiB
Mega Contributor

2 hours ago

Hi I am in process of implementing Azure Ip based cloud discovery.

Please help mme fix this issue
API based discovery is working fine (cloud resources and VM's are getting discovered). I have enable VM schedule which runs after discovery, where am getting "Active couldn't classify error."
We are using Cyber ARK for password management. but the service accounts which are used for credential config are set to static in Cyber Ark.
Discovery Log shows:

java.lang.NoClassDefFoundError: javapasswordsdk/exceptions/PSDKException
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:421)
at java.base/java.lang.Class.forName(Class.java:412)
at com.service_now.mid.services.credential.ICredentialResolverFactory.contractDrivenResolverFactory(ICredentialResolverFactory.java:28)
at com.service_now.mid.services.credential.ResolutionType.createResolver(ResolutionType.java:40)
at com.service_now.mid.services.CredentialResolverProxy.initWithFQCN(CredentialResolverProxy.java:205)
0 Helpfuls
  • 183 Views
4 REPLIES 4

Vikram Reddy
Tera Guru

an hour ago

Hey @KranthiB,

 

That stack trace is not a CyberArk logic problem, it is a MID Server classpath problem. javapasswordsdk/exceptions/PSDKException is a class from AIM's JavaPasswordSDK.jar, and NoClassDefFoundError means the JVM went looking for it on that MID Server and it was not there (or not loaded yet). Since API discovery of the cloud resources does not need OS credentials, it sails through fine, but the VM schedule has to actually log into each instance, so it hits credential resolution and blows up right at CredentialResolverProxy.initWithFQCN trying to forName() the CyberArk resolver class.

Worth checking, in this order:

  • Import the jar again as a MID Server > JAR Files record, even if you already loaded it once, then restart the MID Server service. The classpath only refreshes on restart, a jar drop alone does nothing.
  • For the first run on a given MID host, drop the jar manually into agent/lib. The agent copies it into agent/extlib on next check-in, after that the JAR Files record keeps it in sync.
  • Look in agent/extlib for a stale or duplicate JavaPasswordSDK.jar left over from a manual copy, a version mismatch there causes exactly this error.
  • Confirm every MID Server in the cluster used for this schedule got the jar, not just the one you tested with.

Static vs rotating accounts in CyberArk has nothing to do with this, it is purely the SDK not being on the JVM's classpath.

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls

KranthiB
Mega Contributor

an hour ago

Where can I get these JAR files. Does cyberArk Team provide the Jar files ?

0 Helpfuls

Vikram Reddy
Tera Guru
In response to KranthiB

38m ago

Hi @KranthiB,

 

Good question, and no, ServiceNow does not ship that jar. JavaPasswordSDK.jar is CyberArk's own file, it comes bundled with the AIM Credential Provider (CP) install, the same component that gets installed wherever the Central Credential Provider or Application Identity Manager agent lives. So this one is on your CyberArk/security team, not ServiceNow support.

Practically, here is where to find it:

  • If the CyberArk Credential Provider is already installed on the MID Server host (it usually has to be, for AIM based resolution to work at all), the jar is sitting locally at install_dir/CyberArk/ApplicationPasswordSdk. Ask whoever did the CP install on that box, they will know the path.
  • If the Credential Provider was never installed on the MID Server host, that is actually your real problem, not just a missing jar. The MID Server needs the CP agent present locally to resolve credentials this way, so get your CyberArk admin to push that install first.
  • Once you have it, go to MID Server > JAR Files in ServiceNow, create a new record, and attach JavaPasswordSDK.jar there. Do this even if a copy already exists on the server from a previous manual drop, the JAR Files record is what ServiceNow uses to push and keep it in sync going forward.
  • Restart the MID Server service after. The agent copies the jar into agent/extlib on that restart (or on next check-in), and that is the only point the classpath actually refreshes.

One more thing worth checking while you are in there: since you mentioned CyberArk is managing these as static accounts rather than rotating, double check with your CyberArk admin that the Application ID and safe permissions tied to the CP agent are actually scoped to let it fetch those specific credential objects. That will not throw the NoClassDefFoundError you saw, but it is a common second failure right after the classpath issue clears.

 

Thank you,
Vikram Karety
Octigo Solutions INC

0 Helpfuls