[Feature Request] Allow user custom workstation hostname

[XiaoliChan]

Hello, As Pennyw0rth/NetExec#694 point out, it's possible to allow user specify workstation hostname when initial Client class?

Like this

connection = Client(
...
workstation={hostname user want}
...
)

[jborean93]

The location where the NTLM workstation is set is in pyspnego https://github.com/jborean93/pyspnego/blob/57ff8d2c177a453c4a032df71f80e6bfc9a8ca5c/src/spnego/_ntlm.py#L187. You can do the exact same thing that NetExec does to set the env var NETBIOS_COMPUTER_NAME before calling pypsrp. I cannot expose this option in pypsrp as setting an env var is not thread safe and will affect the entire process so it will break anything using it in a multithreaded environment.

[XiaoliChan]

@jborean93 Thanks for reply

You can do the exact same thing that NetExec does to set the env var NETBIOS_COMPUTER_NAME before calling pypsrp

Yes, I know this, but one thing I have big concern is do os.environ in multi-thread, like thread A and B did env set at the same time, will it break?

[jborean93]

It definitely will step on each other's toes as setting it in one will overwrite the other. I also believe glibc has threading issues with these exact APIs but potentially CPython is good enough to lock it from causing a catastrophic error. Ultimately this is why I can't expose this as an option in pypsrp as it's one thing for an end user to set it themselves and call this but another for a common library to do unsafe thread actions.

[NeffIsBack]

I am not sure if i could follow along. When using the environment variables is not thread safe, why don't we implement a parameter so we can directly inject it into the Client? The hack in NetExec to set a env var is just a hacky workaround so we can control the NetBIOS name used in the NTLM auth, see Pennyw0rth/NetExec#694. Wouldn't it be easier and thread safe to simply add a parameter to the Client class that defines the workstation name that can be filled when instantiating the object?

[jborean93]

Because there is no way for Client to pass that down to the required library. It would also have to set the env var.

[NeffIsBack]

Well, by design there must be an interaction between the Client and spnego, because otherwise the NTLM layer would not receive the credentials provided by the client. From i could tell this flow is Client -> WSMan -> _TransportHTTP -> HTTPNegotiateAuth -> spengo.client() _new_context() -> NTLMProxy which then uses/queries the workstation (NETBIOS_COMPUTER_NAME) os var.

If the decision is made to expose such an optional variable for the workstation name it would feel natural to supply this as an optional parameter alongside the username and password (practically as an additional "auth" parameter), but this decision is ultimately up to you @jborean93.

[jborean93]

From i could tell this flow is Client -> WSMan -> _TransportHTTP -> HTTPNegotiateAuth -> spengo.client() _new_context() -> NTLMProxy which then uses/queries the workstation (NETBIOS_COMPUTER_NAME) os var.

That is true but spnego.client exposes no kwarg to set the workstation name so pypsrp cannot pass through anything and thus expose a value in Client. The only thing it can do today is to do os.environ['NETBIOS_COMPUTER_NAME'] = workstation but as I've said this is not thread safe and would be up to the caller to do as they are the ones in charge of how threading is used.

What would need to happen is for the pyspnego library to expose the ability to set this in spnego.client() somehow but so far I've tried to hold off on adding auth protocol specific options and in most cases I've not seen any reason why a client would need to set a workstation specific value per host vs just having the one value for all.

[NeffIsBack]

What would need to happen is for the pyspnego library to expose the ability to set this in spnego.client() somehow but so far I've tried to hold off on adding auth protocol specific options and in most cases I've not seen any reason why a client would need to set a workstation specific value per host vs just having the one value for all.

Yeah i can see that, my idea was just that it felt weird to retrieve this value via environment variable. (As you are the author of both tools) this is ultimately your decision to make. It would also make things easier for libraries to use the auth protocols and not rely on (potentially wrongfully set) env vars, but i don't know the structure of pyspnego and can't say which place would be a good place to feed this information to the NTLM layer. However, it feels natural to me to feed this along with username/password etc. because it is a client specific information about the connection that should be established.

[jborean93]

Originally pyspnego used either the pure Python NTLM implementation or gss-ntlmssp if it was installed and configured. The environment variable was added in the pure Python implementation to replicate the behaviour in gss-ntlmssp as well as being somewhat useful for testing purposes. While gss-ntlmssp is no longer used in pyspnego the behaviour was kept as I know some people have used it in the past and it didn't seem like it did much harm.

While technically I could find a way to pass through the options, it is somewhat difficult to do and reason with when someone select negotiate auth with the NTLM fallback vs ntlm itself which is why I've been reluctant to add it. Another reason why I never really added an option is there hasn't been any request and the environment variable has been good enough. While setting env vars are not thread safe it is ok to set it before you start the different threads so it is still possible to configure in a Python script that will spawn multiple threads. I'm unsure why you would really want to change the workstation name per thread/target though, setting it one should fit most use cases AFAIK.