locked
WINRM Basic auth disabled RRS feed

  • Question

  • We have upgraded our OS to 2019 and since then can't get Linux agent authentication working. When trying to discovery or install agents we get

    Unexpected DiscoveryResult.ErrorData type.  Please file bug report.
    ErrorData: Microsoft.SystemCenter.CrossPlatform.ClientLibrary.MPAbstractions.WinRMBasicAuthDisabledException
    The WinRM client cannot process the request. Basic authentication is currently disabled in the client configuration. Verify the WinRM client configuration for all management servers in the resource pool and try the request again.
       at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary`2 inputs, WorkflowInstanceExtensionManager extensions, TimeSpan timeout)
       at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary`2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager extensions)
       at Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

    WINRM Basic is disabled per OU policy.  We have made the registry change to enable kerberos but this doesn't seem to change anything.

    After manaually installing or targeting existing agents this command does work so we know Kerberos is working.

    winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -r:https://<host>:1270 -u:<user> -auth:Kerberos -skipcacheck -skipcncheck -encoding:utf-8

    Is Basic auth a requirement for Linux monitoring?  

    Current settings

    C:\Windows\system32>winrm get winrm/config/client/auth
    Auth
        Basic = false [Source="GPO"]
        Digest = false [Source="GPO"]
        Kerberos = true
        Negotiate = true
        Certificate = true
        CredSSP = false

    Tuesday, June 23, 2020 6:22 PM

Answers

  • I found that that someone had imported old SCX certificates onto these servers so they were invalid.  I removed all SCX certs from both management servers and let SCOM recreate them. Then exported and imported each servers cert to the other.

    Next I had to resign all the Linux servers certs so they could be trusted.  

    This solved most servers issues.  A couple still have some other issues but the bulk of Linux monitoring is working again. 

    • Marked as answer by stemo76 Thursday, July 2, 2020 4:54 PM
    Thursday, July 2, 2020 4:54 PM

All replies

  • Hi,

    Since SCOM 1801 Kerberos support was added for the WS-Management communication, and there's no need for basic authentication any longer.

    Now Kerberos for WS-Management does have a few prerequisites:
    https://docs.microsoft.com/en-us/system-center/scom/manage-linux-kerberos-auth?view=sc-om-2019

    Best regards,
    Leon


    Blog: https://thesystemcenterblog.com LinkedIn:

    Tuesday, June 23, 2020 7:00 PM
  • I have done this and confirmed the registry entry

    1. Select Monitoring > Data Warehouse > Collection Servers > Management Server Name.

    2. In the right-hand task pane, select Enable Linux Authentication Type

    I have also tested with this command and it works

    winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -r:https://<UNIX/Linux servername>:1270 -u:<username@contoso.com> -p:<password> -auth:Kerberos -skipcacheck -skipcncheck -encoding:utf-8

    But when running the discovery in the UI I still get the error above indicating that its trying to use WinRM Basic auth or at least its failing because its disabled. 

    Wednesday, June 24, 2020 3:20 PM
  • Which SCOM version are you running?

    Do you meet all the prerequisites?

    Remember that the registry entry has to be done on all SCOM management servers that communicate with the Linux/UNIX agents.


    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, June 24, 2020 3:23 PM
  • Kerberos authentication is not supported for agent install/repair/update operations : https://docs.microsoft.com/en-us/system-center/scom/manage-linux-kerberos-auth?view=sc-om-2019#operations-manager-unix-and-linux-kerberos-support-by-activity
    Wednesday, June 24, 2020 3:38 PM
  • Yep, discovery should work but not installing.

    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, June 24, 2020 3:40 PM
  • The default credentials, user name, and password, are the credentials for the logged-on user account that runs the script.

    To change to another account on a remote computer

    Specify the credentials in a ConnectionOptions or IWSManConnectionOptions object and supply that to the CreateSession call.
    Set the WSManFlagCredUserNamePassword in the flags parameter in the CreateSession call.
    The following list contains a list of what occurs when a script or application runs under the default credentials:

    Kerberos is the default method of authentication when the client is in a domain and the remote destination string is not one of the following: localhost, 127.0.0.1, or [::1].
    Negotiate is the default method when the client is not in a domain, but the remote destination string is one of the following: localhost, 127.0.0.1, or [::1].
    If you supply explicit credentials with a ConnectionOptions object, Negotiate is the default method. Negotiate authentication determines whether the ongoing authentication method is Kerberos or NTLM, depending on whether the computers are in a domain or workgroup. If connecting to a remote target computer using a local account, then the account should be prefixed with the computer name. For example, myComputer\myUsername.

    If you specify Negotiate, Digest, or Basic authentication and fail to supply a ConnectionOptions object, then you will receive an error indicating that explicit credentials are required. If HTTPS is not the transport, then the target remote computer must be configured in the list of trusted host computers.
    Wednesday, June 24, 2020 3:42 PM
  • I just double checked the registry across all 7 of the management servers.  Of course the only one that had the entry missing was the only one that I was attempting to use. I reduced the resource pool down to just 1 server for Linux monitoring so I could target my troubleshooting

    Updating the registry did clear up the WINRM discovery error.  Agents are still not communicating and all grey, even the one I removed and was able to reinstall the agent on.  All tasks I run show complete but have no output. 

    Task Description   Memory Information

    Status:Success
    Scheduled Time:6/24/2020 9:13:32 AM
    Start Time:6/24/2020 9:13:32 AM
    Submitted By:<ME>
    Run As:
    Run Location:
    Target:
    Target Type:Red Hat Enterprise Linux Server 7 Computer
    Category:Maintenance
    Provides available Memory and Swap in MB.


    Task Output:

    ErrorCode

    ErrorMessage

    Wednesday, June 24, 2020 4:15 PM
  • So what authentication type is used for agent push?

    I was able to reinstall the agent on one of the Linux server and this command works against that node

    winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -r:https://<UNIX/Linux servername>:1270 -u:<username@contoso.com> -p:<password> -auth:Kerberos -skipcacheck -skipcncheck -encoding:utf-8

    Wednesday, June 24, 2020 4:17 PM
  • So what authentication type is used for agent push?

    I was able to reinstall the agent on one of the Linux server and this command works against that node

    winrm e http://schemas.microsoft.com/wbem/wscim/1/cim-schema/2/SCX_Agent?__cimnamespace=root/scx -r:https://<UNIX/Linux servername>:1270 -u:<username@contoso.com> -p:<password> -auth:Kerberos -skipcacheck -skipcncheck -encoding:utf-8

    SCOM uses SSH and SFTP for installing, upgrading or removing agents on Linux/UNIX computers.

    Blog: https://thesystemcenterblog.com LinkedIn:

    Wednesday, June 24, 2020 4:21 PM
  • Seems I am working with multiple issues, I updated the resource pool from one management server to another and now the same task as an error due to certificates.  

    Task Description   Memory Information


    Status:Success
    Scheduled Time:6/25/2020 7:40:39 AM
    Start Time:6/25/2020 7:40:39 AM
    Submitted By:<ME>
    Run As:
    Run Location:
    Target:
    Target Type:Red Hat Enterprise Linux Server 7 Computer
    Category:Maintenance
    Provides available Memory and Swap in MB.


    Task Output:

    ErrorCode

    ErrorMessage
    WSManFault
    The server certificate on the destination computer (<HOST>:1270) has the following errors: 
    The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable.    
    The SSL certificate is signed by an unknown certificate authority.      

    I am going to remove the agent and reinstall from the current management server to see if resigning the certificate works. The task in the console to update the cert is not working. 

    The SCXCertWriteAction module encountered a DoProcess exception. The workflow "Microsoft.Unix.Agent.UpdateCert.Task" has been unloaded. 
    Module: SCXCertWriteAction 
    Location: DoProcess 
    Exception type: ScxCertLibException 
    Exception message: Unable to create certificate context 
    ; {ASN1 bad tag value met. 

    Additional data: Sudo path: /etc/opt/microsoft/scx/conf/sudodir/ 
    Management group: <SCOMINSTANCE>
    Workflow name: Microsoft.Unix.Agent.UpdateCert.Task 
    Object name: <HOST> 
    Object ID: {4D9116E2-0FF2-D488-D927-E67E64D0BE5E} 
    Error Code: -2130771918 (Unknown error (0x80ff0032)).

    Thursday, June 25, 2020 2:44 PM
  • I found that that someone had imported old SCX certificates onto these servers so they were invalid.  I removed all SCX certs from both management servers and let SCOM recreate them. Then exported and imported each servers cert to the other.

    Next I had to resign all the Linux servers certs so they could be trusted.  

    This solved most servers issues.  A couple still have some other issues but the bulk of Linux monitoring is working again. 

    • Marked as answer by stemo76 Thursday, July 2, 2020 4:54 PM
    Thursday, July 2, 2020 4:54 PM