@olafhartong Cheap binary representation arithmetic. LONG_MAX minus some round number. I don’t remember what off the top of my head. It’s purely for Linux interop. Windows uses 64 bit time and Kerberos itself is agnostic. We bumped it up recently to nudge some aging libraries along.
@cadenzza_ @JosephRyanRies @NerdPyle The statement stands. It's accurate. We use it internally for things like SC testing. I still don't recommend you build a product on it.
@JosephRyanRies @cadenzza_ @NerdPyle They aren’t going away any time soon, but we aren’t ever going to invest more energy into them. I don’t recommend building a product on them.
@awakecoding@SchwaanK It’s locked behind a feature flag. We’re fixed the final ship bugs but it takes a while for changes to bubble up. Breaking fallback is such a PITA.
@awakecoding@arekfurt The SSH channel is a transparent proxy of the opaque TLS data then? Today, which stage is being told it must auth to localhost? It sounds then like it’s currently violating server auth by design, which isn’t ideal.
@awakecoding@arekfurt I go back to server auth. As long as the thing the user sees is localhost, it connecting to anything but localhost voids the server authentication. It doesn’t matter what the intermediate layers do. If something lies about what it’s connecting to, that’s breaking server auth.
@awakecoding@arekfurt The absolute reality is that 100% is always unattainable. We have a plan for ~92% give or take. The remaining might be covered by attrition, or we do some exceptionally weird things, or we live with it. Or who knows, I may have sold myself right onto an ice flow going out to sea.
@awakecoding@arekfurt At some point we just call it. Our target is when we our metrics hit a ridiculously low number of negotiated NTLM connections. If there are still hard dependencies that require NTLM because insecure behaviors, well maybe we accept that, and they’re stuck manually turning it on.
@arekfurt@awakecoding Anything routed through a thing named localhost means you likely can’t get proper server auth, certainly not for preexisting protocols that have specific server auth semantics. That’s not something I’m interested in solving for, *yet*. Let me kill the 90% use cases first.
@JefTek@EricaZelic In that regard it’s mildly offensive when it gets called legacy or not modern considering just how much of the world runs on it, without issue, every day. It certainly could use some improvements, and it’s getting them. Same as TLS.
@JefTek@EricaZelic I would call the internal distinction something else and it would get me in trouble. Kerberos is like TLS: well defined and underpins literally everything. TLS is not modern by any definition, but it gets improved over time. Kerberos too.
@dwizzzleMSFT @_C_King_123 Compatible with what, sorry? Do you mean an NTLM implementation that’s compatible with Samba? AFAIK they have a built in one. Our NTLM deprecation efforts are coming along nicely too, but the interop with Samba et al is an ongoing process. We’ll have more on that later.
@awakecoding@cnotin Strictly speaking pku2u doesn’t care where the cert is. It relies on certpoleng to do that, and in the AADJ case certpoleng has an AADJ plugin. There’s a certpoleng event log that’s fairly detailed. The application protocol knows nothing about pku2u.
@NathanMcNulty@_dirkjan TAP might have different logic on lifetime. TAP didn’t exist when I wrote the TGT code. We’re talking to the current owners about this. It’s not a vulnerability by our classification since no security boundary has been bypassed, but certainly worth aligning for the stated reasons
@Evil_Mog NO I HAVE BEEN BURNED BY THESE DANG IDS AT LEAST ONCE FRIGGEN EH. Not this one though. There’s a few of these suckers lying in wait to anger you.