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 • david.cu...@newschool.edu<mailto:david.cu...@newschool.edu> On Mon, May 18, 2020 at 3:21 PM mbar...@scad.edu<mailto:mbar...@scad.edu> <mbar...@scad.edu<mailto:mbar...@scad.edu>> 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 • david...@newschool.edu On Mon, May 18, 2020 at 1:49 PM Richard Frovarp <richard...@ndsu.edu> 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, mba...@scad.edu 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 cas-...@apereo.org. 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 cas-user+unsubscr...@apereo.org<mailto:cas-user+unsubscr...@apereo.org>. 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 cas-user+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/07171603c91233042a2b9c487fe45eb665a84b58.camel%40ndsu.edu.
