<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    We wanted verification from Zoom on one final item around SSO and
    just received it.<br>
    <br>
    We are passing as the <NameID> value from Shibboleth to Zoom
    the user's eduPersonUniqueId attribute value. This value is stored
    on the user's Zoom profile, it's just not exposed when looking at a
    user's Zoom profile or a csv export of the Zoom users. You will see
    it in the "SAML Response Logs".<br>
    <br>
    All of the user's not originally created via auto-provisioning
    during a SSO login to our Zoom site, will not (of course) have such
    a <NameID> value.  The first time they login via SSO, email
    address is used as the match, then their profile gets updated with
    their <NameID> value. <br>
    <br>
    If the SAML assertion has a different email address than what's in
    the user's existing Zoom profile (under another license), the user
    will get a new profile based on the SSO login and not a "migrated"
    profile.<br>
    <br>
    <br>
    Don<br>
    <br>
    <div class="moz-cite-prefix">On 8/28/20 8:22 PM, Lohr, Donald A -
      lohrda wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:42090518-43D4-4F1E-91F9-DF523E84DC69@jmu.edu">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div>What we learned. </div>
      <div id="AppleMailSignature"><br>
      </div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">We are releasing eduPersonUniqueId in
          the Shibboleth SAML assertion in the nameid field. On our Zoom
          SSO "SAML Response Mapping" we set <NameID> as the
          "Employee Unique ID" value. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">We are doing SSO auto-provisioning. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">When using <NameID> as the
          unique profile key in lieu of Zoom's default email address,
          Zoom tracks when the user's email address is set on the
          profile and will not allow it to update again once the
          existing email value is 12 hours old. See Gotcha#2 below. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">We were able to successfully test
          this <NameID> model by getting to the left of the @ and
          even to the right of @ in the email address changes to update
          a user's Zoom profile. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature">Gotcha#1: </div>
      <div id="AppleMailSignature">The "Associated Domains" setting has
        to be configured with your email domain(s) before the use of the
        <NameID> in your Zoom configuration will manage and update
        your email values when they change. For us, we have two email
        domains. The "Associated Domains" item also has to be configured
        so you pull into your Zoom site license all of those users that
        had an existing Zoom license based on their email address from
        your email domain(s). </div>
      <div id="AppleMailSignature"><br>
      </div>
      <div id="AppleMailSignature">Gotcha#2: Once a Zoom profile is
        created or it was just updated with a new email address value,
        Zoom will not allow a change to the email field on said user's
        Zoom profile for 12 hours. Meaning if a user's email address
        changes in your LDAP directory at 8:00am and user logs into
        their existing Zoom profile (say) at 08:15am and their new email
        address updates their Zoom profile. If then at 10:00am the
        <span style="background-color: rgba(255, 255, 255, 0);">user's
          email address changes again in your LDAP directory and the
          user tries to login again to Zoom at 10:30, they will get a
          Zoom error page. If you look in your Zoom's site "SAML
          Response Logs" for that user's login, using the view details
          link, toward the bottom you will see reference to the 12 hour
          window. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">Once the 12 hours has past, the
          user's next Zoom login will update their Zoom profile with the
          new email address. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">I have asked our account rep "why 12
          hours" and even recommended a site specific setting that might
          better align with our business processes but have not gotten
          any response yet. </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);"><br>
        </span></div>
      <div id="AppleMailSignature"><span style="background-color:
          rgba(255, 255, 255, 0);">Don</span></div>
      <div id="AppleMailSignature"><br>
        <span style="background-color: rgba(255, 255, 255, 0);">-- <br>
          D o n a l d   L o h r<br>
          I n f o r m a t i o n   S y s t e m s<br>
          J a m e s   M a d i s o n   U n i v e r s i t y<br>
          5 4 0 . 5 6 8 . 3 7 3 0</span></div>
      <div><br>
        On Aug 21, 2020, at 10:42 PM, Lohr, Donald A - lohrda <<a
          href="mailto:lohrda@jmu.edu" moz-do-not-send="true">lohrda@jmu.edu</a>>
        wrote:<br>
        <br>
      </div>
      <blockquote type="cite">
        <div>
          <p style="margin: 0px; line-height: normal; font-family: '.SF
            UI Text'; color: rgb(69, 69, 69);">
            <span style="font-family: '.SFUIText'; font-size: 17pt;"><a
href="https://urldefense.proofpoint.com/v2/url?u=https-3A__support.zoom.us_hc_en-2Dus_articles_201363003-2DGetting-2Dstarted-2Dwith-2DSSO&d=DwMGaQ&c=eLbWYnpnzycBCgmb7vCI4uqNEB9RSjOdn_5nBEmmeq0&r=Pa2DB88IW_s2TyLfktHtWA&m=fLnm-WN9U4d94T42-8yB77D1UNg2gyNoFMXbDF8Oh9w&s=apt4aG3d0K1Wv8QERvPkmi6ynRplZudGFD6sPI3ZN8c&e="
                moz-do-not-send="true">https://support.zoom.us/hc/en-us/articles/201363003-Getting-started-with-SSO</a></span></p>
        </div>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
D o n a l d   L o h r
I n f o r m a t i o n   S y s t e m s
J a m e s   M a d i s o n   U n i v e r s i t y
5 4 0 . 5 6 8 . 3 7 3 0
</pre>
  </body>
</html>