Re: [cas-user] disabling MFA, MFA failure modes

['jhawkesworth' via CAS Community]

Just to follow up (in a less huge font) 
https://github.com/apereo/cas/pull/3509 

 fixed 
the  INVALID_AUTHENTICATION_CONTEXT issue for me.

All the best,

Jon

On Monday, September 10, 2018 at 4:41:26 PM UTC+1, Jon Hawkesworth wrote:
>
> Great, thank you so much for tackling this!
>
> As soon as I have figured out the best way for me to test your PR I will 
> comment on it.
>
> Jon
>
> On Mon, 10 Sep 2018 at 16:30, Travis Schmidt  > wrote:
>
>> PR (https://github.com/apereo/cas/pull/3509) has been submitted to 
>> correct this.  
>>
>> On Mon, Sep 10, 2018 at 8:03 AM Travis Schmidt > > wrote:
>>
>>> This is an issue where if you indicate bypass from a script, the the 
>>> authentication is not correctly marked as being bypassed and the context 
>>> validator then rejects.  Also be aware that currently if you choose GROOVY 
>>> or REST for bypass providers, this overrides all rules in DEFAULT.  Meaning 
>>> if you mark a service as "Bypass Enabled" in your service registry, the 
>>> bypass will not be honored, unless you write your script to check that 
>>> flag.   
>>>  
>>>
>>> On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk >> > wrote:
>>>
 I'm literally dealing with the same error and decision of trigger vs 
 bypass right now. We were triggering all users for Duo, then deciding in 
 the groovy script which to bypass. This works fine when simply judging by 
 the prompt for Duo or not, but we also got the 
 INVALID_AUTHENTICATION_CONTEXT 
 when the service validates the ticket. The logs indicate the validation 
 was 
 successful which seems to lead to a problem building the validation 
 response.

 I am in the process of moving our logic to the trigger groovy script, 
 which appears to provide the desired behavior. I'm not clear on the 
 intended use case of "trigger" vs "bypass" or what the ramification of 
 this 
 move will be, however.

 -dirk

 On Mon, Sep 10, 2018 at 9:55 AM 'jhawkesworth' via CAS Community <
 cas-...@apereo.org > wrote:

> Thanks for this thread.
>
> I think perhaps having a groovy script which determines whether or not 
> to bypass DUO might be the way forward?
>
> In theory you can just change the groovy script (on each CAS node) if 
> DUO is degraded and subsequent requests would then take notice of new 
> bypass policy.
>
> That said, I'm not able to get duo bypass fully working using with a 
> groovy script.  The /login works, correctly identifying if duo is needed 
> depending on our selection criteria, but /servicevalidate still fails 
> with 
>
> INVALID_AUTHENTICATION_CONTEXT
>
>
> Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT, 
> so should have  https://github.com/apereo/cas/pull/3493 included but 
> I'm still getting the INVALID_AUTHENTICATION_CONTEXT failure for all 
> users 
> (not just those who should/shouldn't be required to 2FA) as soon as I 
> configure duo for a service.
>
> Can anyone share how they have got bypass working with DUO?
>
> This comment 
> https://github.com/apereo/cas/pull/3493#discussion_r213138134 
>
>- "There is no bypassProvider created currently unless one is 
>defined in cas.properties" seems to hint that something needs explicit 
>configuration in cas.properties.
>
>
> I am just setting the following (along with the duo keys):
>
> cas.authn.mfa.duo[0].id=mfa-duo
> cas.authn.mfa.duo[0].bypass.type=GROOVY
>
> cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy
>
> Am I missing something?
>
> Debugging into AbstractServiceValidateController it appears there's no 
> bypassEvaluator for duo (see below), so this is presumably why cas things 
> it needs to get duo to do something in order to validate the ST.
>
> duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null,
>  
> globalFailureMode=null, id=mfa-duo, order=0)
>
> Somewhat related, I'm wondering if I should instead by using 'trigger' 
> instead of 'bypass' - are they simply semantic default-not-to-try / 
> default-is-to-try or is there something more subtle going on?In my 
> case 
> some users won't even be registered with DUO 
>
> Any help greatly appreciated.  
>
> All the best,
>
> Jon
>
>
>
> On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:
>>
>> A closer review of the cas properties documentation suggests that 
>> setting cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired 
>> effect after all. It doesn't disable MFA, just assumes the MFA provider 
>> is 
>>

Re: [cas-user] disabling MFA, MFA failure modes

[Jon Hawkesworth]

Great, thank you so much for tackling this!

As soon as I have figured out the best way for me to test your PR I will
comment on it.

Jon

On Mon, 10 Sep 2018 at 16:30, Travis Schmidt 
wrote:

> PR (https://github.com/apereo/cas/pull/3509) has been submitted to
> correct this.
>
> On Mon, Sep 10, 2018 at 8:03 AM Travis Schmidt 
> wrote:
>
>> This is an issue where if you indicate bypass from a script, the the
>> authentication is not correctly marked as being bypassed and the context
>> validator then rejects.  Also be aware that currently if you choose GROOVY
>> or REST for bypass providers, this overrides all rules in DEFAULT.  Meaning
>> if you mark a service as "Bypass Enabled" in your service registry, the
>> bypass will not be honored, unless you write your script to check that
>> flag.
>>
>>
>> On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk  wrote:
>>
>>> I'm literally dealing with the same error and decision of trigger vs
>>> bypass right now. We were triggering all users for Duo, then deciding in
>>> the groovy script which to bypass. This works fine when simply judging by
>>> the prompt for Duo or not, but we also got the 
>>> INVALID_AUTHENTICATION_CONTEXT
>>> when the service validates the ticket. The logs indicate the validation was
>>> successful which seems to lead to a problem building the validation
>>> response.
>>>
>>> I am in the process of moving our logic to the trigger groovy script,
>>> which appears to provide the desired behavior. I'm not clear on the
>>> intended use case of "trigger" vs "bypass" or what the ramification of this
>>> move will be, however.
>>>
>>> -dirk
>>>
>>> On Mon, Sep 10, 2018 at 9:55 AM 'jhawkesworth' via CAS Community <
>>> cas-user@apereo.org> wrote:
>>>
 Thanks for this thread.

 I think perhaps having a groovy script which determines whether or not
 to bypass DUO might be the way forward?

 In theory you can just change the groovy script (on each CAS node) if
 DUO is degraded and subsequent requests would then take notice of new
 bypass policy.

 That said, I'm not able to get duo bypass fully working using with a
 groovy script.  The /login works, correctly identifying if duo is needed
 depending on our selection criteria, but /servicevalidate still fails with

 INVALID_AUTHENTICATION_CONTEXT


 Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT,
 so should have  https://github.com/apereo/cas/pull/3493 included but
 I'm still getting the INVALID_AUTHENTICATION_CONTEXT failure for all users
 (not just those who should/shouldn't be required to 2FA) as soon as I
 configure duo for a service.

 Can anyone share how they have got bypass working with DUO?

 This comment
 https://github.com/apereo/cas/pull/3493#discussion_r213138134

- "There is no bypassProvider created currently unless one is
defined in cas.properties" seems to hint that something needs explicit
configuration in cas.properties.


 I am just setting the following (along with the duo keys):

 cas.authn.mfa.duo[0].id=mfa-duo
 cas.authn.mfa.duo[0].bypass.type=GROOVY

 cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy

 Am I missing something?

 Debugging into AbstractServiceValidateController it appears there's no
 bypassEvaluator for duo (see below), so this is presumably why cas things
 it needs to get duo to do something in order to validate the ST.

 duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null,
 globalFailureMode=null, id=mfa-duo, order=0)

 Somewhat related, I'm wondering if I should instead by using 'trigger'
 instead of 'bypass' - are they simply semantic default-not-to-try /
 default-is-to-try or is there something more subtle going on?In my case
 some users won't even be registered with DUO

 Any help greatly appreciated.

 All the best,

 Jon



 On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:
>
> A closer review of the cas properties documentation suggests that
> setting cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired
> effect after all. It doesn't disable MFA, just assumes the MFA provider is
> avialable. So I should back up and reformulate my question:
>
> Is there a way to configure CAS to disable MFA globally, ideally via
> the cas.properties file in a way that will override anything that may be
> set in an individual service registration? I suppose you could take the
> dependency out of the overlay and rebuild CAS, but that seems like 
> overkill
> (and would that approach cause it to choke on MFA references already
> present in the cas.properties or services registrations?).
>
> On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fu

Re: [cas-user] disabling MFA, MFA failure modes

[Travis Schmidt]

PR (https://github.com/apereo/cas/pull/3509) has been submitted to correct
this.

On Mon, Sep 10, 2018 at 8:03 AM Travis Schmidt 
wrote:

> This is an issue where if you indicate bypass from a script, the the
> authentication is not correctly marked as being bypassed and the context
> validator then rejects.  Also be aware that currently if you choose GROOVY
> or REST for bypass providers, this overrides all rules in DEFAULT.  Meaning
> if you mark a service as "Bypass Enabled" in your service registry, the
> bypass will not be honored, unless you write your script to check that
> flag.
>
>
> On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk  wrote:
>
>> I'm literally dealing with the same error and decision of trigger vs
>> bypass right now. We were triggering all users for Duo, then deciding in
>> the groovy script which to bypass. This works fine when simply judging by
>> the prompt for Duo or not, but we also got the INVALID_AUTHENTICATION_CONTEXT
>> when the service validates the ticket. The logs indicate the validation was
>> successful which seems to lead to a problem building the validation
>> response.
>>
>> I am in the process of moving our logic to the trigger groovy script,
>> which appears to provide the desired behavior. I'm not clear on the
>> intended use case of "trigger" vs "bypass" or what the ramification of this
>> move will be, however.
>>
>> -dirk
>>
>> On Mon, Sep 10, 2018 at 9:55 AM 'jhawkesworth' via CAS Community <
>> cas-user@apereo.org> wrote:
>>
>>> Thanks for this thread.
>>>
>>> I think perhaps having a groovy script which determines whether or not
>>> to bypass DUO might be the way forward?
>>>
>>> In theory you can just change the groovy script (on each CAS node) if
>>> DUO is degraded and subsequent requests would then take notice of new
>>> bypass policy.
>>>
>>> That said, I'm not able to get duo bypass fully working using with a
>>> groovy script.  The /login works, correctly identifying if duo is needed
>>> depending on our selection criteria, but /servicevalidate still fails with
>>>
>>> INVALID_AUTHENTICATION_CONTEXT
>>>
>>>
>>> Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT, so
>>> should have  https://github.com/apereo/cas/pull/3493 included but I'm
>>> still getting the INVALID_AUTHENTICATION_CONTEXT failure for all users (not
>>> just those who should/shouldn't be required to 2FA) as soon as I configure
>>> duo for a service.
>>>
>>> Can anyone share how they have got bypass working with DUO?
>>>
>>> This comment
>>> https://github.com/apereo/cas/pull/3493#discussion_r213138134
>>>
>>>- "There is no bypassProvider created currently unless one is
>>>defined in cas.properties" seems to hint that something needs explicit
>>>configuration in cas.properties.
>>>
>>>
>>> I am just setting the following (along with the duo keys):
>>>
>>> cas.authn.mfa.duo[0].id=mfa-duo
>>> cas.authn.mfa.duo[0].bypass.type=GROOVY
>>>
>>> cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy
>>>
>>> Am I missing something?
>>>
>>> Debugging into AbstractServiceValidateController it appears there's no
>>> bypassEvaluator for duo (see below), so this is presumably why cas things
>>> it needs to get duo to do something in order to validate the ST.
>>>
>>> duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null,
>>> globalFailureMode=null, id=mfa-duo, order=0)
>>>
>>> Somewhat related, I'm wondering if I should instead by using 'trigger'
>>> instead of 'bypass' - are they simply semantic default-not-to-try /
>>> default-is-to-try or is there something more subtle going on?In my case
>>> some users won't even be registered with DUO
>>>
>>> Any help greatly appreciated.
>>>
>>> All the best,
>>>
>>> Jon
>>>
>>>
>>>
>>> On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:

 A closer review of the cas properties documentation suggests that
 setting cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired
 effect after all. It doesn't disable MFA, just assumes the MFA provider is
 avialable. So I should back up and reformulate my question:

 Is there a way to configure CAS to disable MFA globally, ideally via
 the cas.properties file in a way that will override anything that may be
 set in an individual service registration? I suppose you could take the
 dependency out of the overlay and rebuild CAS, but that seems like overkill
 (and would that approach cause it to choke on MFA references already
 present in the cas.properties or services registrations?).

 On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fujimoto wrote:
 >Yes, we're essentially relying on the Duo integration to determine
 whether the user needs MFA and we're hitting Duo with every AuthN. Our CAS
 isn't currently set configured up to check a group for Duo-enabled
 membership. Thus our desire to simply disable MFA altogether (by executive
>

Re: [cas-user] disabling MFA, MFA failure modes

[Travis Schmidt]

This is an issue where if you indicate bypass from a script, the the
authentication is not correctly marked as being bypassed and the context
validator then rejects.  Also be aware that currently if you choose GROOVY
or REST for bypass providers, this overrides all rules in DEFAULT.  Meaning
if you mark a service as "Bypass Enabled" in your service registry, the
bypass will not be honored, unless you write your script to check that
flag.


On Mon, Sep 10, 2018 at 7:15 AM Tepe, Dirk  wrote:

> I'm literally dealing with the same error and decision of trigger vs
> bypass right now. We were triggering all users for Duo, then deciding in
> the groovy script which to bypass. This works fine when simply judging by
> the prompt for Duo or not, but we also got the INVALID_AUTHENTICATION_CONTEXT
> when the service validates the ticket. The logs indicate the validation was
> successful which seems to lead to a problem building the validation
> response.
>
> I am in the process of moving our logic to the trigger groovy script,
> which appears to provide the desired behavior. I'm not clear on the
> intended use case of "trigger" vs "bypass" or what the ramification of this
> move will be, however.
>
> -dirk
>
> On Mon, Sep 10, 2018 at 9:55 AM 'jhawkesworth' via CAS Community <
> cas-user@apereo.org> wrote:
>
>> Thanks for this thread.
>>
>> I think perhaps having a groovy script which determines whether or not to
>> bypass DUO might be the way forward?
>>
>> In theory you can just change the groovy script (on each CAS node) if DUO
>> is degraded and subsequent requests would then take notice of new bypass
>> policy.
>>
>> That said, I'm not able to get duo bypass fully working using with a
>> groovy script.  The /login works, correctly identifying if duo is needed
>> depending on our selection criteria, but /servicevalidate still fails with
>>
>> INVALID_AUTHENTICATION_CONTEXT
>>
>>
>> Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT, so
>> should have  https://github.com/apereo/cas/pull/3493 included but I'm
>> still getting the INVALID_AUTHENTICATION_CONTEXT failure for all users (not
>> just those who should/shouldn't be required to 2FA) as soon as I configure
>> duo for a service.
>>
>> Can anyone share how they have got bypass working with DUO?
>>
>> This comment
>> https://github.com/apereo/cas/pull/3493#discussion_r213138134
>>
>>- "There is no bypassProvider created currently unless one is defined
>>in cas.properties" seems to hint that something needs explicit
>>configuration in cas.properties.
>>
>>
>> I am just setting the following (along with the duo keys):
>>
>> cas.authn.mfa.duo[0].id=mfa-duo
>> cas.authn.mfa.duo[0].bypass.type=GROOVY
>>
>> cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy
>>
>> Am I missing something?
>>
>> Debugging into AbstractServiceValidateController it appears there's no
>> bypassEvaluator for duo (see below), so this is presumably why cas things
>> it needs to get duo to do something in order to validate the ST.
>>
>> duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null,
>> globalFailureMode=null, id=mfa-duo, order=0)
>>
>> Somewhat related, I'm wondering if I should instead by using 'trigger'
>> instead of 'bypass' - are they simply semantic default-not-to-try /
>> default-is-to-try or is there something more subtle going on?In my case
>> some users won't even be registered with DUO
>>
>> Any help greatly appreciated.
>>
>> All the best,
>>
>> Jon
>>
>>
>>
>> On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:
>>>
>>> A closer review of the cas properties documentation suggests that
>>> setting cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired
>>> effect after all. It doesn't disable MFA, just assumes the MFA provider is
>>> avialable. So I should back up and reformulate my question:
>>>
>>> Is there a way to configure CAS to disable MFA globally, ideally via the
>>> cas.properties file in a way that will override anything that may be set in
>>> an individual service registration? I suppose you could take the dependency
>>> out of the overlay and rebuild CAS, but that seems like overkill (and would
>>> that approach cause it to choke on MFA references already present in the
>>> cas.properties or services registrations?).
>>>
>>> On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fujimoto wrote:
>>> >Yes, we're essentially relying on the Duo integration to determine
>>> whether the user needs MFA and we're hitting Duo with every AuthN. Our CAS
>>> isn't currently set configured up to check a group for Duo-enabled
>>> membership. Thus our desire to simply disable MFA altogether (by executive
>>> decision) in dire circumstances.
>>> >
>>> >On Tue, Sep 04, 2018 at 03:39:14PM -0500, Richard Frovarp wrote:
>>> >>Yeah, but how do they opt in? You're basically relying on the Duo
>>> integration
>>> >>to come back and say that the user needs to MFA? 

Re: [cas-user] disabling MFA, MFA failure modes

[Tepe, Dirk]

I'm literally dealing with the same error and decision of trigger vs bypass
right now. We were triggering all users for Duo, then deciding in the
groovy script which to bypass. This works fine when simply judging by the
prompt for Duo or not, but we also got the INVALID_AUTHENTICATION_CONTEXT
when the service validates the ticket. The logs indicate the validation was
successful which seems to lead to a problem building the validation
response.

I am in the process of moving our logic to the trigger groovy script, which
appears to provide the desired behavior. I'm not clear on the intended use
case of "trigger" vs "bypass" or what the ramification of this move will
be, however.

-dirk

On Mon, Sep 10, 2018 at 9:55 AM 'jhawkesworth' via CAS Community <
cas-user@apereo.org> wrote:

> Thanks for this thread.
>
> I think perhaps having a groovy script which determines whether or not to
> bypass DUO might be the way forward?
>
> In theory you can just change the groovy script (on each CAS node) if DUO
> is degraded and subsequent requests would then take notice of new bypass
> policy.
>
> That said, I'm not able to get duo bypass fully working using with a
> groovy script.  The /login works, correctly identifying if duo is needed
> depending on our selection criteria, but /servicevalidate still fails with
>
> INVALID_AUTHENTICATION_CONTEXT
>
>
> Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT, so
> should have  https://github.com/apereo/cas/pull/3493 included but I'm
> still getting the INVALID_AUTHENTICATION_CONTEXT failure for all users (not
> just those who should/shouldn't be required to 2FA) as soon as I configure
> duo for a service.
>
> Can anyone share how they have got bypass working with DUO?
>
> This comment https://github.com/apereo/cas/pull/3493#discussion_r213138134
>
>
>- "There is no bypassProvider created currently unless one is defined
>in cas.properties" seems to hint that something needs explicit
>configuration in cas.properties.
>
>
> I am just setting the following (along with the duo keys):
>
> cas.authn.mfa.duo[0].id=mfa-duo
> cas.authn.mfa.duo[0].bypass.type=GROOVY
>
> cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy
>
> Am I missing something?
>
> Debugging into AbstractServiceValidateController it appears there's no
> bypassEvaluator for duo (see below), so this is presumably why cas things
> it needs to get duo to do something in order to validate the ST.
>
> duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null,
> globalFailureMode=null, id=mfa-duo, order=0)
>
> Somewhat related, I'm wondering if I should instead by using 'trigger'
> instead of 'bypass' - are they simply semantic default-not-to-try /
> default-is-to-try or is there something more subtle going on?In my case
> some users won't even be registered with DUO
>
> Any help greatly appreciated.
>
> All the best,
>
> Jon
>
>
>
> On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:
>>
>> A closer review of the cas properties documentation suggests that setting
>> cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired effect after
>> all. It doesn't disable MFA, just assumes the MFA provider is avialable. So
>> I should back up and reformulate my question:
>>
>> Is there a way to configure CAS to disable MFA globally, ideally via the
>> cas.properties file in a way that will override anything that may be set in
>> an individual service registration? I suppose you could take the dependency
>> out of the overlay and rebuild CAS, but that seems like overkill (and would
>> that approach cause it to choke on MFA references already present in the
>> cas.properties or services registrations?).
>>
>> On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fujimoto wrote:
>> >Yes, we're essentially relying on the Duo integration to determine
>> whether the user needs MFA and we're hitting Duo with every AuthN. Our CAS
>> isn't currently set configured up to check a group for Duo-enabled
>> membership. Thus our desire to simply disable MFA altogether (by executive
>> decision) in dire circumstances.
>> >
>> >On Tue, Sep 04, 2018 at 03:39:14PM -0500, Richard Frovarp wrote:
>> >>Yeah, but how do they opt in? You're basically relying on the Duo
>> integration
>> >>to come back and say that the user needs to MFA? That means that you're
>> >>hitting Duo every auth, even if the user hasn't opted in. Which means
>> these
>> >>sorts of events are really nasty if that is the case. I also can't
>> remember
>> >>which one it was, but either CAS or Shibboleth were asserting that MFA
>> had
>> >>happened if Duo came back and said that the user didn't have to MFA. So
>> the
>> >>attribute release back to SPs started to get ugly.
>> >>
>> >>Like I said with ours, we check an AD group first. So we don't even
>> query the
>> >>Duo integration until that group check passes. The integration is
>> configured
>> >>to always require 

Re: [cas-user] disabling MFA, MFA failure modes

['jhawkesworth' via CAS Community]

Thanks for this thread.

I think perhaps having a groovy script which determines whether or not to 
bypass DUO might be the way forward?

In theory you can just change the groovy script (on each CAS node) if DUO 
is degraded and subsequent requests would then take notice of new bypass 
policy.

That said, I'm not able to get duo bypass fully working using with a groovy 
script.  The /login works, correctly identifying if duo is needed depending 
on our selection criteria, but /servicevalidate still fails with 

INVALID_AUTHENTICATION_CONTEXT


Just to be clear I am running against latest snapshot 5.3.4-SNAPSHOT, so 
should have  https://github.com/apereo/cas/pull/3493 included but I'm still 
getting the INVALID_AUTHENTICATION_CONTEXT failure for all users (not just 
those who should/shouldn't be required to 2FA) as soon as I configure duo 
for a service.

Can anyone share how they have got bypass working with DUO?

This comment https://github.com/apereo/cas/pull/3493#discussion_r213138134 

   - "There is no bypassProvider created currently unless one is defined in 
   cas.properties" seems to hint that something needs explicit configuration 
   in cas.properties.


I am just setting the following (along with the duo keys):

cas.authn.mfa.duo[0].id=mfa-duo
cas.authn.mfa.duo[0].bypass.type=GROOVY
cas.authn.mfa.duo[0].bypass.groovy.location=file:/etc/cas/config/mfa-bypass.groovy

Am I missing something?

Debugging into AbstractServiceValidateController it appears there's no 
bypassEvaluator for duo (see below), so this is presumably why cas things 
it needs to get duo to do something in order to validate the ST.

duoMultifactorAuthenticationProvider=AbstractMultifactorAuthenticationProvider(bypassEvaluator=null,
 
globalFailureMode=null, id=mfa-duo, order=0)

Somewhat related, I'm wondering if I should instead by using 'trigger' 
instead of 'bypass' - are they simply semantic default-not-to-try / 
default-is-to-try or is there something more subtle going on?In my case 
some users won't even be registered with DUO 

Any help greatly appreciated.  

All the best,

Jon



On Saturday, September 8, 2018 at 4:37:08 AM UTC+1, baron wrote:
>
> A closer review of the cas properties documentation suggests that setting 
> cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired effect after 
> all. It doesn't disable MFA, just assumes the MFA provider is avialable. So 
> I should back up and reformulate my question: 
>
> Is there a way to configure CAS to disable MFA globally, ideally via the 
> cas.properties file in a way that will override anything that may be set in 
> an individual service registration? I suppose you could take the dependency 
> out of the overlay and rebuild CAS, but that seems like overkill (and would 
> that approach cause it to choke on MFA references already present in the 
> cas.properties or services registrations?). 
>
> On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fujimoto wrote: 
> >Yes, we're essentially relying on the Duo integration to determine 
> whether the user needs MFA and we're hitting Duo with every AuthN. Our CAS 
> isn't currently set configured up to check a group for Duo-enabled 
> membership. Thus our desire to simply disable MFA altogether (by executive 
> decision) in dire circumstances. 
> > 
> >On Tue, Sep 04, 2018 at 03:39:14PM -0500, Richard Frovarp wrote: 
> >>Yeah, but how do they opt in? You're basically relying on the Duo 
> integration 
> >>to come back and say that the user needs to MFA? That means that you're 
> >>hitting Duo every auth, even if the user hasn't opted in. Which means 
> these 
> >>sorts of events are really nasty if that is the case. I also can't 
> remember 
> >>which one it was, but either CAS or Shibboleth were asserting that MFA 
> had 
> >>happened if Duo came back and said that the user didn't have to MFA. So 
> the 
> >>attribute release back to SPs started to get ugly. 
> >> 
> >>Like I said with ours, we check an AD group first. So we don't even 
> query the 
> >>Duo integration until that group check passes. The integration is 
> configured 
> >>to always require MFA is it is asked. 
> >> 
> >>I certainly get your point about not wanting to change all of them. I'm 
> in 
> >>part saying that the last two issues appeared to have failed in two 
> different 
> >>ways, neither of which is one that the library anticipated. If I ever 
> get 
> >>some time, I'd like to look at how the code is working, and improve it. 
> But 
> >>I'm 90% sure that out of the box there is no way to configure it so that 
> it 
> >>would have handle either of those two incidents, as it wasn't going to 
> detect 
> >>them. Your best bet would have been to block traffic at the edge so that 
> Duo 
> >>wasn't even reachable. Then the ping would have failed, and CAS would 
> have 
> >>had a chance to fall into its error handling routines for MFA. 
> >> 
> >>On 09/04/2018 03:21 PM, Baron Fujimoto wrote: 
> >>> We're enabling Duo via the multifactor sec

Re: [cas-user] disabling MFA, MFA failure modes

[Baron Fujimoto]

A closer review of the cas properties documentation suggests that setting 
cas.authn.mfa.globalFailureMode=NONE wouldn't have the desired effect after 
all. It doesn't disable MFA, just assumes the MFA provider is avialable. So I 
should back up and reformulate my question:

Is there a way to configure CAS to disable MFA globally, ideally via the 
cas.properties file in a way that will override anything that may be set in an 
individual service registration? I suppose you could take the dependency out of 
the overlay and rebuild CAS, but that seems like overkill (and would that 
approach cause it to choke on MFA references already present in the 
cas.properties or services registrations?).

On Tue, Sep 04, 2018 at 05:59:58PM -1000, Baron Fujimoto wrote:
>Yes, we're essentially relying on the Duo integration to determine whether the 
>user needs MFA and we're hitting Duo with every AuthN. Our CAS isn't currently 
>set configured up to check a group for Duo-enabled membership. Thus our desire 
>to simply disable MFA altogether (by executive decision) in dire circumstances.
>
>On Tue, Sep 04, 2018 at 03:39:14PM -0500, Richard Frovarp wrote:
>>Yeah, but how do they opt in? You're basically relying on the Duo integration
>>to come back and say that the user needs to MFA? That means that you're
>>hitting Duo every auth, even if the user hasn't opted in. Which means these
>>sorts of events are really nasty if that is the case. I also can't remember
>>which one it was, but either CAS or Shibboleth were asserting that MFA had
>>happened if Duo came back and said that the user didn't have to MFA. So the
>>attribute release back to SPs started to get ugly.
>>
>>Like I said with ours, we check an AD group first. So we don't even query the
>>Duo integration until that group check passes. The integration is configured
>>to always require MFA is it is asked.
>>
>>I certainly get your point about not wanting to change all of them. I'm in
>>part saying that the last two issues appeared to have failed in two different
>>ways, neither of which is one that the library anticipated. If I ever get
>>some time, I'd like to look at how the code is working, and improve it. But
>>I'm 90% sure that out of the box there is no way to configure it so that it
>>would have handle either of those two incidents, as it wasn't going to detect
>>them. Your best bet would have been to block traffic at the edge so that Duo
>>wasn't even reachable. Then the ping would have failed, and CAS would have
>>had a chance to fall into its error handling routines for MFA.
>>
>>On 09/04/2018 03:21 PM, Baron Fujimoto wrote:
>>> We're enabling Duo via the multifactor section in each service registration 
>>> as below. However, this is in our default service registration template and 
>>> is present in our hundreds of registered services (our users currently 
>>> opt-in to MFA/Duo). It would be, uhh, non-optimal for us to have to go in 
>>> and tweak each such registration in events like this. We had been hoping 
>>> that setting cas.authn.mfa.globalFailureMode in the global cas.properties 
>>> config would supercede the properties in the individual service 
>>> registrations which would allow us to just have to make the manual 
>>> adjustment there if necessary.
>>> 
>>> On Tue, Sep 04, 2018 at 10:07:08AM -0500, Richard Frovarp wrote:
>>> > I think that CAS does an API ping to check availability. At least that's 
>>> > what
>>> > I saw in the code when I took a peak a couple of months ago. We're also on
>>> > DUO1, and that was succeeding during the DUO1 outages. In fact, it
>>> > immediately succeeded. I even called out the fact that this was happening 
>>> > to
>>> > Duo, and they directed me to the contingency plan document. The issue 
>>> > during
>>> > those outages was that all of the requests were queuing up, and so the
>>> > connection was alive, but nothing useful was happening. Not sure what 
>>> > sort of
>>> > timeouts are involved, but they are quite long.
>>> > 
>>> > During the first outage, it was failing for us at the Duo widget display
>>> > screen. During the second outage, it was failing after credentials, but
>>> > before the widget screen. I haven't looked, but I'm guessing that CAS is
>>> > doing some sort of pre-auth or other API check after login, and before 
>>> > widget
>>> > display to decide if that should be invoked. Given that the page rendered,
>>> > but the widget didn't, it looks like the failure from the first outage (at
>>> > least for us) was a timeout on the browser side, which isn't something 
>>> > that
>>> > CAS will be able to detect. Being able to timeout on the CAS side quickly
>>> > would have helped with the second time. I don't think we're configured to
>>> > fail open, but I also don't think that would have helped.
>>> > 
>>> > How are you deciding to do Duo? We're doing a AD group check. So our
>>> > contingency was/is to change the config file to any group that doesn't 
>>> > match
>>> > an existing group. Th

Re: [cas-user] disabling MFA, MFA failure modes

[Baron Fujimoto]

Yes, we're essentially relying on the Duo integration to determine whether the 
user needs MFA and we're hitting Duo with every AuthN. Our CAS isn't currently 
set configured up to check a group for Duo-enabled membership. Thus our desire 
to simply disable MFA altogether (by executive decision) in dire circumstances.

On Tue, Sep 04, 2018 at 03:39:14PM -0500, Richard Frovarp wrote:
>Yeah, but how do they opt in? You're basically relying on the Duo integration
>to come back and say that the user needs to MFA? That means that you're
>hitting Duo every auth, even if the user hasn't opted in. Which means these
>sorts of events are really nasty if that is the case. I also can't remember
>which one it was, but either CAS or Shibboleth were asserting that MFA had
>happened if Duo came back and said that the user didn't have to MFA. So the
>attribute release back to SPs started to get ugly.
>
>Like I said with ours, we check an AD group first. So we don't even query the
>Duo integration until that group check passes. The integration is configured
>to always require MFA is it is asked.
>
>I certainly get your point about not wanting to change all of them. I'm in
>part saying that the last two issues appeared to have failed in two different
>ways, neither of which is one that the library anticipated. If I ever get
>some time, I'd like to look at how the code is working, and improve it. But
>I'm 90% sure that out of the box there is no way to configure it so that it
>would have handle either of those two incidents, as it wasn't going to detect
>them. Your best bet would have been to block traffic at the edge so that Duo
>wasn't even reachable. Then the ping would have failed, and CAS would have
>had a chance to fall into its error handling routines for MFA.
>
>On 09/04/2018 03:21 PM, Baron Fujimoto wrote:
>> We're enabling Duo via the multifactor section in each service registration 
>> as below. However, this is in our default service registration template and 
>> is present in our hundreds of registered services (our users currently 
>> opt-in to MFA/Duo). It would be, uhh, non-optimal for us to have to go in 
>> and tweak each such registration in events like this. We had been hoping 
>> that setting cas.authn.mfa.globalFailureMode in the global cas.properties 
>> config would supercede the properties in the individual service 
>> registrations which would allow us to just have to make the manual 
>> adjustment there if necessary.
>> 
>> On Tue, Sep 04, 2018 at 10:07:08AM -0500, Richard Frovarp wrote:
>> > I think that CAS does an API ping to check availability. At least that's 
>> > what
>> > I saw in the code when I took a peak a couple of months ago. We're also on
>> > DUO1, and that was succeeding during the DUO1 outages. In fact, it
>> > immediately succeeded. I even called out the fact that this was happening 
>> > to
>> > Duo, and they directed me to the contingency plan document. The issue 
>> > during
>> > those outages was that all of the requests were queuing up, and so the
>> > connection was alive, but nothing useful was happening. Not sure what sort 
>> > of
>> > timeouts are involved, but they are quite long.
>> > 
>> > During the first outage, it was failing for us at the Duo widget display
>> > screen. During the second outage, it was failing after credentials, but
>> > before the widget screen. I haven't looked, but I'm guessing that CAS is
>> > doing some sort of pre-auth or other API check after login, and before 
>> > widget
>> > display to decide if that should be invoked. Given that the page rendered,
>> > but the widget didn't, it looks like the failure from the first outage (at
>> > least for us) was a timeout on the browser side, which isn't something that
>> > CAS will be able to detect. Being able to timeout on the CAS side quickly
>> > would have helped with the second time. I don't think we're configured to
>> > fail open, but I also don't think that would have helped.
>> > 
>> > How are you deciding to do Duo? We're doing a AD group check. So our
>> > contingency was/is to change the config file to any group that doesn't 
>> > match
>> > an existing group. Then the local check fails and it doesn't even try Duo.
>> > That requires human intervention. But a quick touch of the config file 
>> > after
>> > change causes it to immediately reload and take the changes into effect. We
>> > do something similar with Shibboleth IdP for InCommon.
>> > 
>> > On 08/31/2018 11:01 PM, Baron Fujimoto wrote:
>> > > We're considering contingencies to MFA failures in light of recent 
>> > > service problems with Duo.
>> > > 
>> > > We're currently still using CAS 5.0.x. I'm assuming the property of 
>> > > interest for us here is cas.authn.mfa.globalFailureMode. The 
>> > > documentation doesn't really make this clear, but specifically what MFA 
>> > > is/isn't "communicated to the client if provider" is unavailable for 
>> > > PHANTOM/OPEN modes? How does these differ from NONE?
>> > > 
>> > > 

Re: [cas-user] disabling MFA, MFA failure modes

[Richard Frovarp]

Yeah, but how do they opt in? You're basically relying on the Duo 
integration to come back and say that the user needs to MFA? That means 
that you're hitting Duo every auth, even if the user hasn't opted in. 
Which means these sorts of events are really nasty if that is the case. 
I also can't remember which one it was, but either CAS or Shibboleth 
were asserting that MFA had happened if Duo came back and said that the 
user didn't have to MFA. So the attribute release back to SPs started to 
get ugly.


Like I said with ours, we check an AD group first. So we don't even 
query the Duo integration until that group check passes. The integration 
is configured to always require MFA is it is asked.


I certainly get your point about not wanting to change all of them. I'm 
in part saying that the last two issues appeared to have failed in two 
different ways, neither of which is one that the library anticipated. If 
I ever get some time, I'd like to look at how the code is working, and 
improve it. But I'm 90% sure that out of the box there is no way to 
configure it so that it would have handle either of those two incidents, 
as it wasn't going to detect them. Your best bet would have been to 
block traffic at the edge so that Duo wasn't even reachable. Then the 
ping would have failed, and CAS would have had a chance to fall into its 
error handling routines for MFA.


On 09/04/2018 03:21 PM, Baron Fujimoto wrote:

We're enabling Duo via the multifactor section in each service registration as 
below. However, this is in our default service registration template and is 
present in our hundreds of registered services (our users currently opt-in to 
MFA/Duo). It would be, uhh, non-optimal for us to have to go in and tweak each 
such registration in events like this. We had been hoping that setting 
cas.authn.mfa.globalFailureMode in the global cas.properties config would 
supercede the properties in the individual service registrations which would 
allow us to just have to make the manual adjustment there if necessary.

On Tue, Sep 04, 2018 at 10:07:08AM -0500, Richard Frovarp wrote:

I think that CAS does an API ping to check availability. At least that's what
I saw in the code when I took a peak a couple of months ago. We're also on
DUO1, and that was succeeding during the DUO1 outages. In fact, it
immediately succeeded. I even called out the fact that this was happening to
Duo, and they directed me to the contingency plan document. The issue during
those outages was that all of the requests were queuing up, and so the
connection was alive, but nothing useful was happening. Not sure what sort of
timeouts are involved, but they are quite long.

During the first outage, it was failing for us at the Duo widget display
screen. During the second outage, it was failing after credentials, but
before the widget screen. I haven't looked, but I'm guessing that CAS is
doing some sort of pre-auth or other API check after login, and before widget
display to decide if that should be invoked. Given that the page rendered,
but the widget didn't, it looks like the failure from the first outage (at
least for us) was a timeout on the browser side, which isn't something that
CAS will be able to detect. Being able to timeout on the CAS side quickly
would have helped with the second time. I don't think we're configured to
fail open, but I also don't think that would have helped.

How are you deciding to do Duo? We're doing a AD group check. So our
contingency was/is to change the config file to any group that doesn't match
an existing group. Then the local check fails and it doesn't even try Duo.
That requires human intervention. But a quick touch of the config file after
change causes it to immediately reload and take the changes into effect. We
do something similar with Shibboleth IdP for InCommon.

On 08/31/2018 11:01 PM, Baron Fujimoto wrote:

We're considering contingencies to MFA failures in light of recent service 
problems with Duo.

We're currently still using CAS 5.0.x. I'm assuming the property of interest for us here 
is cas.authn.mfa.globalFailureMode. The documentation doesn't really make this clear, but 
specifically what MFA is/isn't "communicated to the client if provider" is 
unavailable for PHANTOM/OPEN modes? How does these differ from NONE?



We also MFA enabled for each registered service with the following:

"multifactorPolicy" : {
  "@class" : 
"org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
  "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet", [ 
"mfa-duo" ] ],
  "failureMode" : "OPEN"
}

I appears however, that setting cas.authn.mfa.globalFailureMode=NONE in 
cas.properties is not sufficient to disable/bypass MFA. I am still prompted for 
it. Should globalFailureMode in cas.properties take precedence over failureMode 
in the serv

Re: [cas-user] disabling MFA, MFA failure modes

[Baron Fujimoto]

We're enabling Duo via the multifactor section in each service registration as 
below. However, this is in our default service registration template and is 
present in our hundreds of registered services (our users currently opt-in to 
MFA/Duo). It would be, uhh, non-optimal for us to have to go in and tweak each 
such registration in events like this. We had been hoping that setting 
cas.authn.mfa.globalFailureMode in the global cas.properties config would 
supercede the properties in the individual service registrations which would 
allow us to just have to make the manual adjustment there if necessary.

On Tue, Sep 04, 2018 at 10:07:08AM -0500, Richard Frovarp wrote:
>I think that CAS does an API ping to check availability. At least that's what
>I saw in the code when I took a peak a couple of months ago. We're also on
>DUO1, and that was succeeding during the DUO1 outages. In fact, it
>immediately succeeded. I even called out the fact that this was happening to
>Duo, and they directed me to the contingency plan document. The issue during
>those outages was that all of the requests were queuing up, and so the
>connection was alive, but nothing useful was happening. Not sure what sort of
>timeouts are involved, but they are quite long.
>
>During the first outage, it was failing for us at the Duo widget display
>screen. During the second outage, it was failing after credentials, but
>before the widget screen. I haven't looked, but I'm guessing that CAS is
>doing some sort of pre-auth or other API check after login, and before widget
>display to decide if that should be invoked. Given that the page rendered,
>but the widget didn't, it looks like the failure from the first outage (at
>least for us) was a timeout on the browser side, which isn't something that
>CAS will be able to detect. Being able to timeout on the CAS side quickly
>would have helped with the second time. I don't think we're configured to
>fail open, but I also don't think that would have helped.
>
>How are you deciding to do Duo? We're doing a AD group check. So our
>contingency was/is to change the config file to any group that doesn't match
>an existing group. Then the local check fails and it doesn't even try Duo.
>That requires human intervention. But a quick touch of the config file after
>change causes it to immediately reload and take the changes into effect. We
>do something similar with Shibboleth IdP for InCommon.
>
>On 08/31/2018 11:01 PM, Baron Fujimoto wrote:
>> We're considering contingencies to MFA failures in light of recent service 
>> problems with Duo.
>> 
>> We're currently still using CAS 5.0.x. I'm assuming the property of interest 
>> for us here is cas.authn.mfa.globalFailureMode. The documentation doesn't 
>> really make this clear, but specifically what MFA is/isn't "communicated to 
>> the client if provider" is unavailable for PHANTOM/OPEN modes? How does 
>> these differ from NONE?
>> 
>> 
>> 
>> We also MFA enabled for each registered service with the following:
>> 
>>"multifactorPolicy" : {
>>  "@class" : 
>> "org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
>>  "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet", [ 
>> "mfa-duo" ] ],
>>  "failureMode" : "OPEN"
>>}
>> 
>> I appears however, that setting cas.authn.mfa.globalFailureMode=NONE in 
>> cas.properties is not sufficient to disable/bypass MFA. I am still prompted 
>> for it. Should globalFailureMode in cas.properties take precedence over 
>> failureMode in the service registration, or vice versa? Or is this not the 
>> right way to achieve this goal?
>> 
>> We are thinking that OPEN may not be desired in the rare cases where Duo may 
>> be technically available (how does CAS detemine Duo's availability?), but 
>> the service has degraded unacceptably.
>> 
>
>-- 
>- 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/a7ca2d94-cb76-46af-164e-c3dd4784e044%40ndsu.edu.

-- 
Baron Fujimoto  :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum

-- 
- 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-u

Re: [cas-user] disabling MFA, MFA failure modes

[Richard Frovarp]

I think that CAS does an API ping to check availability. At least that's 
what I saw in the code when I took a peak a couple of months ago. We're 
also on DUO1, and that was succeeding during the DUO1 outages. In fact, 
it immediately succeeded. I even called out the fact that this was 
happening to Duo, and they directed me to the contingency plan document. 
The issue during those outages was that all of the requests were queuing 
up, and so the connection was alive, but nothing useful was happening. 
Not sure what sort of timeouts are involved, but they are quite long.


During the first outage, it was failing for us at the Duo widget display 
screen. During the second outage, it was failing after credentials, but 
before the widget screen. I haven't looked, but I'm guessing that CAS is 
doing some sort of pre-auth or other API check after login, and before 
widget display to decide if that should be invoked. Given that the page 
rendered, but the widget didn't, it looks like the failure from the 
first outage (at least for us) was a timeout on the browser side, which 
isn't something that CAS will be able to detect. Being able to timeout 
on the CAS side quickly would have helped with the second time. I don't 
think we're configured to fail open, but I also don't think that would 
have helped.


How are you deciding to do Duo? We're doing a AD group check. So our 
contingency was/is to change the config file to any group that doesn't 
match an existing group. Then the local check fails and it doesn't even 
try Duo. That requires human intervention. But a quick touch of the 
config file after change causes it to immediately reload and take the 
changes into effect. We do something similar with Shibboleth IdP for 
InCommon.


On 08/31/2018 11:01 PM, Baron Fujimoto wrote:

We're considering contingencies to MFA failures in light of recent service 
problems with Duo.

We're currently still using CAS 5.0.x. I'm assuming the property of interest for us here 
is cas.authn.mfa.globalFailureMode. The documentation doesn't really make this clear, but 
specifically what MFA is/isn't "communicated to the client if provider" is 
unavailable for PHANTOM/OPEN modes? How does these differ from NONE?



We also MFA enabled for each registered service with the following:

   "multifactorPolicy" : {
 "@class" : 
"org.apereo.cas.services.DefaultRegisteredServiceMultifactorPolicy",
 "multifactorAuthenticationProviders" : [ "java.util.LinkedHashSet", [ 
"mfa-duo" ] ],
 "failureMode" : "OPEN"
   }

I appears however, that setting cas.authn.mfa.globalFailureMode=NONE in 
cas.properties is not sufficient to disable/bypass MFA. I am still prompted for 
it. Should globalFailureMode in cas.properties take precedence over failureMode 
in the service registration, or vice versa? Or is this not the right way to 
achieve this goal?

We are thinking that OPEN may not be desired in the rare cases where Duo may be 
technically available (how does CAS detemine Duo's availability?), but the 
service has degraded unacceptably.



--
- 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/a7ca2d94-cb76-46af-164e-c3dd4784e044%40ndsu.edu.