Highlighted
bpainter Frequent Contributor.
Frequent Contributor.
200 views

Windows 10 Enterprise 1903 ARSO and OES Client

Environment: 

OES Client 2 SP4 IR12

OES 2015.1/SLES/eDir

Zen 2017

Win 10 x64 Enterprise build 1809

We have not upgraded to build 1903 as of yet but was curious if the ARSO issue in the below forum post has been resolved?

https://community.microfocus.com/t5/OES-User-Discussions/Windows-10-issues-with-OES-client/td-p/2575046

Thanks,

Brad

 

Labels (1)
0 Likes
1 Reply
Micro Focus Expert
Micro Focus Expert

Re: Windows 10 Enterprise 1903 ARSO and OES Client

This issue has not been resolved, to our knowledge.  Our engagement with Microsoft's Group Policy support on this could not reach any conclusions on the evidence that had been captured.  And without a way to duplicate the issue reliably enough to generate new evidence with requested debuggin, they didn't have enough to dig further.

I don't want to rule out that Microsoft couldn't have still done something in later 1903 or 1909 releases, since the issue did seem to be "there is a case when the ARSO policy is being reset back to default (enabled) and then re-applied back to the configured state (disabled)."  And presumably by nothing more than timing "luck", LSASS just happened to read and execute based on that policy state during the brief moment it was in the default state instead of the configured state.

But if there was any mitigation to how LSASS or GPSVC refreshes this policy state such that this is now a non-issue in later releases, it is not something that has been communicated to or seen by us.

From the Client for Open Enterprise Server end, the ARSO re-login authentication information remains "opaque" and not a format Microsoft supplied the ability to decrypt or dereference.  Which keeps us from being able to leverage existing functionalities such as "Login with Third-Party Credential Provider" as a way to handle the ARSO case.

Not that this would even be the definitive or "best" way to handle ARSO from a Client for Open Enterprise Server perspective.  Since eDirectory logins may not be in sync with Windows account passwords, or may not be password-based at all.  "Simply prevent the ARSO login in the first place" was definitely more ideal for how eDirectory login occurs in conjunction with the Windows account logon.

We do still have an open enhancement request asking to "improve our ARSO interaction", but it's waiting for a new opportunity or new information to become available for how to better integrate with Windows' ARSO intentions.

But for the more immediate issue, no, we were not able to solve why Windows was being seen to sometimes still perform an ARSO logon, even though Windows was configured to not use ARSO.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.