<div dir="ltr">Yes, my understanding is that Windows client users are authenticated via their domain login alone and that enabling that access without additional prompt for credentials was the a "requirement" of our deployment. And yes, that hinders implementing MFA for the Windows thick clients.<div><br></div><div>David</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 29, 2019 at 9:53 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/29/19, 1:43 PM, "IAM David Bantz" <<a href="mailto:db@alaska.edu" target="_blank">db@alaska.edu</a>> wrote:<br>
<br>
> 1. Both thick (Windows) clients and web browser interface is supported. To support both as seamlessly as possible, our<br>
> AD team asked that we identify users of the web client with an identifier including the Windows domain, like<br>
> ua\username. This required  ginning up that identifier in attribute-resolver.xml<br>
<br>
We support SSO for both thick client and browser, and both use email address IDs just fine (not that I'm advocating it, but in practice email vs. domain naming is functionally the same, it's likely name based on just as good/bad as the other). It's SAML either way. If there's a domain login feature for the thick client (SPNEGO), we didn't use it, but that would be a probable reason for pushing the domain naming. It's also probably a bad choice, since it's a giant pain to support compared to browser-based login, and you lose MFA, etc.<br>
<br>
-- Scott<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>