Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, June 23, 2020 6:22 PM
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
All replies (11)
Thursday, July 2, 2020 4:54 PM âś…Answered
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.
Tuesday, June 23, 2020 7:00 PM
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:
/en-us/system-center/scom/manage-linux-kerberos-auth?view=sc-om-2019
Best regards,
Leon
Blog: https://thesystemcenterblog.com LinkedIn:
Wednesday, June 24, 2020 3:20 PM
I have done this and confirmed the registry entry
Select Monitoring > Data Warehouse > Collection Servers > Management Server Name.
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:<[email protected]> -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:23 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:38 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:40 PM
Yep, discovery should work but not installing.
Blog: https://thesystemcenterblog.com LinkedIn:
Wednesday, June 24, 2020 3:42 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 4:15 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: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:<[email protected]> -p:<password> -auth:Kerberos -skipcacheck -skipcncheck -encoding:utf-8
Wednesday, June 24, 2020 4:21 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:<[email protected]> -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:
Thursday, June 25, 2020 2:44 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)).