4 ms·
In addition to what was said above: In later versions, LFS doesn't play nice with misconfigured internal networks based on Microsoft's Azure / Active Directory
by olvy0 4y ago
In addition to what was said above:
In later versions, LFS doesn't play nice with misconfigured internal networks based on Microsoft's Azure / Active Directory. The LFS project dropped support for NTLM (for good reasons) but it's difficult to convince IT to switch to Kerberos. Our team have been trying to do that for several weeks now. So the result is that if we want to use LFS we are stuck with old versions of LFS which still supported NTLM, which necessitate using old versions of GIT which supported this old version of LFS, else we run into all sorts of weird error messages. Also the same combination of old GIT + old LFS works perfectly on some machines, and fails with some weird error messages on others. Possibly due to another IT misconfiguration or something.
I've been wanting for a while now to check if I can fork LFS and fix this, unfortunately my knowledge of golang is very sketchy. Hopefully we'll manage to convince IT to drop NTLM support from the on-premise Azure.
- e12e 4y ago> Hopefully we'll manage to convince IT to drop NTLM support from the on-premise Azure. What year is this? ;) On a more serious note - ntlm, really? And with azure ad, not a regular (old) on-premise domain? I know it can be hard to drag windows setups into the future (hello WINS!) - But why keep ntlm auth in a post windows 7 world? Legacy systems without ldap/radius support? Genuinely curious (and a little horrified).
- olvy0 4y agoTell me about it ;) Apparently, it's related to the few win 7 machines that are still present somewhere in the organization for various reasons. All of them are airgapped (I hope) so there's no real reason to keep NTLM, but nobody has yet made the decision. Working on getting to the guy in charge to authorize it. Sigh.