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/CA%2Bd9XAM8v-MhiXGvArsTS0RZ%2BcbFFwe6jX3MmxaPdJNL%3DBz-ew%40mail.gmail.com.
