If the double-account people are still the exception rather than the rule (even with a couple hundred), I recommend a consistent naming scheme for them with a prefix or something (like our "adm_netid"). Then you can just refer to "your xyz account" where "xyz" is the prefix, and it's always clear which one you're talking about.
-- DAVID A. CURRY, CISSP *DIRECTOR • INFORMATION SECURITY & PRIVACY* THE NEW SCHOOL • INFORMATION TECHNOLOGY 71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003 +1 646 909-4728 • [email protected] On Mon, May 18, 2020 at 5:12 PM [email protected] <[email protected]> wrote: > Thank you again for responding. I wish we didn't split email, but we did > a long time ago - during the initial email implementation - and we never > tried to consolidate. > > Fortunately, I don't have the "which account" problems. Students get a > pretty clear setup, and anything extra would go to a staff account. I just > have a couple of services (email, file sharing) where certain people are > going to have a separate student and staff account. I need a clear way for > the user (and CAS) to know which account. I think your idea of separate > logins will handle that, but we'll just need to communicate with those > double-account people. > > Thanks again, > Mike > > > On Monday, May 18, 2020 at 4:25:03 PM UTC-4, richard.frovarp wrote: >> >> Now I get to say "Same as Dave". Secondary accounts are for administrator >> or test access for the most part in our environment. Splitting something >> like email is a pain, and that has spawned a great many threads over on the >> Educause IAM (née Idm) list. Bigger issue is making sure others know which >> account to reference to grant permissions. >> >> On Mon, 2020-05-18 at 15:26 -0400, David Curry wrote: >> >> In our case no, because the "staff" account is really just an >> "administrator" account -- so it's the one used to be an application (or >> system) admin rather than the user's regular account. Most of the people >> who have those are IT people, although a few non-IT people are starting to >> get them as we roll out new applications and systems. >> >> So when I log into an application (like the CAS management console, or >> the Duo admin pages, or a Linux box where I want to use "sudo" to do root-y >> things, or a Windows server where I need admin rights), I log in as >> "adm_curryd" instead of "curryd". When I want to do things as a normal >> person, I log in as "curryd". >> >> --Dave >> >> -- >> >> DAVID A. CURRY, CISSP >> *DIRECTOR • INFORMATION SECURITY & PRIVACY* >> THE NEW SCHOOL • INFORMATION TECHNOLOGY >> >> 71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003 >> +1 646 909-4728 • [email protected] >> >> >> On Mon, May 18, 2020 at 3:21 PM [email protected] <[email protected]> wrote: >> >> David, Richard, >> >> Thank you very much. Did you or do you have issues with students/staff >> getting confused on which account to use? Any tips for handling that other >> than FAQs? We've got several hundred people with dual accounts. >> >> Thank you, >> Mike >> >> On Monday, May 18, 2020 at 2:05:05 PM UTC-4, David Curry wrote: >> >> We do pretty much the same thing Richard is doing. The different accounts >> are in different OUs in AD, and IAM handles the provisioning. Way back >> when, we configured CAS with multiple "directories" that are the same AD >> server with different DNs (one for each OU). We could probably stop doing >> that now and just use one "directory" with a less-specific OU, but it's >> working fine the way it is. >> >> We don't have separate Duo setups; we are using the alternate username >> feature of Duo that Richard mentioned to allow multiple accounts to use the >> same profile. We also use that feature to handle this one stupid app we >> have that insists on the username being shaped like an email address. >> >> -- >> >> DAVID A. CURRY, CISSP >> *DIRECTOR • INFORMATION SECURITY & PRIVACY* >> THE NEW SCHOOL • INFORMATION TECHNOLOGY >> >> 71 FIFTH AVE., 9TH FL., NEW YORK, NY 10003 >> +1 646 909-4728 • [email protected] >> >> >> On Mon, May 18, 2020 at 1:49 PM Richard Frovarp <[email protected]> >> wrote: >> >> We just have separate accounts in AD, which is where we are >> authenticating and doing attribute release from. The IAM system is >> responsible for correctly populating the directory and end application >> if needed in the correct way for each account. This requires multiple >> accounts and passwords, and currently multiple Duo setups. Although, >> thinking of it now, we could use alternate usernames on Duo to use the >> same configuration between different accounts. >> >> On Mon, 2020-05-18 at 10:19 -0700, [email protected] wrote: >> > At our university, we have some applications where one person will >> > only have one account and the application is aware of the different >> > "roles" a person might have, i.e., student, staff, faculty and/or >> > alumni. We also have some other applications where a person may >> > have a student account and also a faculty/staff account. Due to >> > historical reasons, our CAS is built around the former, one-person- >> > to-one-account model. Up until now, we've a been able to handle >> > multiple accounts via separate login URLs to the same service, and >> > CAS will respond with the appropriate staff or student attributes. >> > >> > We're now integrating with some Cloud services and the separate login >> > URL does not appear to be a possibility. We'll just have one URL for >> > the Cloud service. >> > >> > How are other organizations handling this? I'd love to hear some >> > ideas. >> > >> > I can think of a couple ways, but I'm not sure I like them. >> > >> > Thank you very much, >> > Mike >> >> -- >> - Website: https://apereo.github.io/cas >> - Gitter Chatroom: https://gitter.im/apereo/cas >> - List Guidelines: https://goo.gl/1VRrw7 >> - Contributions: https://goo.gl/mh7qDG >> --- >> You received this message because you are subscribed to the Google Groups >> "CAS Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/apereo.org/d/msgid/cas-user/792d3a4e0fe3167f3ec9f165b8e6ead0744d9a71.camel%40ndsu.edu >> . >> >> -- >> - Website: https://apereo.github.io/cas >> - Gitter Chatroom: https://gitter.im/apereo/cas >> - List Guidelines: https://goo.gl/1VRrw7 >> - Contributions: https://goo.gl/mh7qDG >> --- >> You received this message because you are subscribed to the Google Groups >> "CAS Community" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/a/apereo.org/d/msgid/cas-user/adbd9e26-f115-4775-9dbf-f120ca764494%40apereo.org >> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/adbd9e26-f115-4775-9dbf-f120ca764494%40apereo.org?utm_medium=email&utm_source=footer> >> . >> >> -- > - Website: https://apereo.github.io/cas > - Gitter Chatroom: https://gitter.im/apereo/cas > - List Guidelines: https://goo.gl/1VRrw7 > - Contributions: https://goo.gl/mh7qDG > --- > You received this message because you are subscribed to the Google Groups > "CAS Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/apereo.org/d/msgid/cas-user/142106a4-1f34-4457-b600-e8ded9f48258%40apereo.org > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/142106a4-1f34-4457-b600-e8ded9f48258%40apereo.org?utm_medium=email&utm_source=footer> > . > -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CA%2Bd9XAPBcGztEt6E78qqwg6z_Kk2_BKt-oUQugCL6w0hnk4L8w%40mail.gmail.com.
