Wsman with kerberos gssapi


This document describes how to configure OpenNMS to allow Kerberos GSSAPI authentication for WSMAN services. It follows the configuration I use in my own environment. As usual, your mileage may vary.


  • If running Oracle Java, Java JCE Unlimited Strength (not needed with modern versions of OpenJDK)
  • Working Kerberos configuration, preferably on your OpenNMS server
  • Kerberos client packages
  • The ability to create Active Directory users
  • The ability to assign user permissions to WMI namespaces on your Windows server(s)

Create an Active Directory user

Create a user account for OpenNMS to use for GSSAPI authentication. Preferably, use a non-expiring password so you do not have to continually re-create your keytab when it expires. In all further examples, this is represented as your-user@REALM.COM

Create a kerberos keytab for the user

On a kerberos-enabled Linux system, create a keytab for the user you created. The steps below work for an Active Directory Kerberos realm, but may require a different encryption type ( -e ) for different Kerberos providers.

# ktutil 
> addent -password -p your-user@REALM.COM -k 1 -e RC4-HMAC 
- enter password for your-user - 
> wkt username.keytab 
> q 
  • steps would be similar for creating a keytab on a Windows system where ktutil is available.
  • ktutil comes from the krb5-workstation package on RHEL family, should be similar in the Debian world.

Now test the file by invoking:

kinit your-user@REALM.COM -kt username.keytab

It should not prompt for your password nor should it give any other feedback. if it is successful, you should see a tgt via klist:

# klist 
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: your-user@REALM.COM

Valid starting     Expires            Service principal
08/03/18 11:32:49  08/03/18 21:32:49  krbtgt/REALM.COM@REALM.COM
        renew until 08/10/18 11:32:49

Copy this keytab somewhere β€œsafe”. I like ${OPENNMS_HOME}/etc/creds/username.keytab - you will need to remember this path, as we will use it later.

Create the JAAS login.conf configuration

Create a JAAS login configuration for WSMan at ${OPENNMS_HOME}/etc/login.conf :

WSManClient { required 
  • Note that in the example above we have defined debug=true . This is helpful for initial configuration and troubleshooting, but should be changed to debug=false once the configuration is verified working.

Edit or create opennms.conf

Now that you have a kerberized user, a useable keytab, and the JAAS login configuration in place, the JVM has to be made Kerberos-aware. Edit or create ${OPENNMS_HOME}/etc/opennms.conf :

  • Note that in the example above we have defined . This is helpful for initial configuration and troubleshooting, but enables some extremely verbose logging and should not be left set true once the configuration is verified working.
  • The location of your krb5.conf may be different. Verify.
  • Replace ${OPENNMS_HOME} in this example with the actual path.

Update wsman-config.xml

The definition you add or create can be tailored to your environment. The below is provided as an example.

<?xml version="1.0"?>
<wsman-config retry="1" timeout="30000" ssl="true" strict-ssl="false" path="/wsman" username="root" password="calvin">
   <definition ssl="false" port="5985" path="/wsman" gss-auth="true" username="your-user" password="your-user-password"> <range begin="" end=""/>  
  • I don’t recall if the plain-text password is actually required.
  • gss-auth should be true for the definition.
  • port, path default values here are correct for Windows wsman.
  • ssl status is determined by your environment and requirements.

Grant permissions to your user on the target

Assuming the target is a Windows host, there are some permissions required in order to access the wmi namespace.

Add the user to the built-in Remote Management Users group.

And grant the user permissions to access the CIMV2 WMI namespace:

  • Make sure to Allow Remote Enable for your user.
  • You could perhaps use Group Policy to automate this across a large number of nodes.
  • For full access to the WMI tree to collect all system metrics, the user should be a member of the local administrators group

Configure the WinRM listener

The most expedient way is to open a command prompt (open as administrator ) and use winrm quickconfig

You must either:


git clone the repo, and follow the included instructions to compile the WsManCli tool. You can test gssapi and access in general by:

# java \ \ \ \ \ -jar ./cli/target/org.opennms.core.wsman.cli-1.2.3-SNAPSHOT.jar \
 -gssAuth \ 
 -o enum \ 
 -r \
 -vvv \
 -w WSMAN_1_0 \
 -resourceUri* \
 "select Name,Status from Win32_Service where Name = 'WinRM' and StartMode='Auto'"

The above command uses the system krb5.conf and the login.conf as created above to configure gssapi, and executes a WQL query for the state of the WinRM service. A successful command would return scimilar to:

[INFO ] 
2018-08-03 12:52:14.315 [main] EnumerationOperations - Inbound Message
ID: 1
Response-Code: 200
Encoding: UTF-8
Content-Type: application/soap+xml;charset=UTF-8
Headers: {Content-Length=[914], content-type=[application/soap+xml;charset=UTF-8], Date=[Fri, 03 Aug 2018 17:52:14 GMT], Server=[Microsoft-HTTPAPI/2.0], WWW-Authenticate=[Negotiate dgweg5tyhrgdfg56yuhsgfthisisgibberishrty5676776ydfhsssssvrebbyw4t23/r353tergfe552tr4y4bywvedyfty699herpilk68hderpb4narf5r2q31wzzq3er3v45345w3v]}
Payload: <s:Envelope xmlns:s="" xmlns:a="" xmlns:n="" xmlns:w="" xml:lang="en-US">
        <w:XmlFragment xmlns:xsi="" xmlns:w="">
[INFO ] org.opennms.core.wsman.WSManCli 2018-08-03 12:52:14.370 [main] WSManCli - Succesfully pulled 1 nodes. XmlFragment ( 
Name = WinRM 
Status = OK

:woman_facepalming: You can fix me, I’m a wiki post.

1 Like