A customer has reported that a call to the TranslateName Win32 API is failing with an access denied error when constructing a WindowsSessionUser with their AD setup; their AD does not support SAM account names.
What was the solution? (How)
The TranslateName call was not necessary, so it has been removed. It appears to have been put in place to be able to extract a domain for a LogonUser call that is used to check that the user+password are correct. However, LogonUser does not require that a domain be passed to it.
What is the impact of this change?
Users should be able to use this library for cross-user Sessions regardless of their AD setup.
Fixes: https://github.com/OpenJobDescription/openjd-sessions-for-python/issues/142
What was the problem/requirement? (What/Why)
A customer has reported that a call to the TranslateName Win32 API is failing with an access denied error when constructing a WindowsSessionUser with their AD setup; their AD does not support SAM account names.
What was the solution? (How)
The TranslateName call was not necessary, so it has been removed. It appears to have been put in place to be able to extract a domain for a LogonUser call that is used to check that the user+password are correct. However, LogonUser does not require that a domain be passed to it.
What is the impact of this change?
Users should be able to use this library for cross-user Sessions regardless of their AD setup.
How was this change tested?
I've run the unit tests as per the impersonation testing instructions: https://github.com/OpenJobDescription/openjd-sessions-for-python/blob/mainline/DEVELOPMENT.md#user-impersonation-windows-based-systems
The result is a full pass.
Was this change documented?
Not necessary.
Is this a breaking change?
No
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.