Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
I have the same issue with 7.0.3 and Duo MFA, I am also hoping for a fix
with 7.1, Thank you Ray and Mike.
On Wed, Apr 17, 2024 at 9:53 AM Mike S wrote:
> You're right! Removing support-surrogate-webflow allows merging to proceed
> properly. Think this will be addressed in 7.1, or is this working as
> intended and we have to do something else to enable proper attribute
> merging?
>
> On Tuesday, April 16, 2024 at 8:55:32 p.m. UTC-2:30 Ray Bon wrote:
>
>> I have been able to confirm that the presence of the surrogate log in
>> feature can create the observed problem.
>>
>> implementation "org.apereo.cas:cas-server-support-surrogate-webflow"
>>
>> The non merging of attributes happens even though no surrogate login
>> takes place.
>>
>> Ray
>>
>> On Mon, 2024-04-15 at 12:30 -0700, Mike S wrote:
>>
>> Notice: This message was sent from outside the University of Victoria
>> email system. Please be cautious with links and sensitive information.
>>
>> FYI, downgrading to 6.6.13 works. DUO universal prompt functions properly
>> and the principal attributes are from LDAP only. I'm suspicious that
>> something about DUO and/or MFA is broken in CAS 7.0.3.
>>
>> On Monday, April 15, 2024 at 2:10:54 p.m. UTC-2:30 Mike S wrote:
>>
>> Hi Ray,
>>
>> it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:
>>
>>
>>
>> /var/log/cas
>> *debug*
>>
>> On Saturday, April 13, 2024 at 1:48:06 a.m. UTC-2:30 Ray Bon wrote:
>>
>> Mike,
>>
>> What logger did you enable to see this?
>>
>> Ray
>>
>> On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
>>
>> Notice: This message was sent from outside the University of Victoria
>> email system. Please be cautious with links and sensitive information.
>>
>> Thanks for your response Ray. I've been banging my head against this for
>> a while and I thought it was something I was missing. I've verified the
>> conflict resolver option doesn't work.
>>
>> The log debug log output shows the LDAP and DUO attributes at one point
>> are merged, but the result is discarded.
>>
>> Is there a suggested workaround?
>>
>> On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
>>
>> Mike,
>>
>> I can confirm this behaviour.
>> DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The
>> change was in 5bcef20 about 5 months ago.
>>
>> The old behaviour was to select the first principle in a list; new
>> behaviour defaults to last.
>> Even setting this property,
>>
>> cas.person-directory.principal-resolution-conflict-strategy=first
>>
>> does not work.
>>
>> Printing the list of principals immediately before
>> PrincipalElectionStrategyConflictResolver is invoked:
>>
>> 2024-04-11 23:40:23,144 ERROR [
>> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - > SimplePrincipal(id=rbon, attributes={cn=[Ray Bon],
>> description=[ROLE_ADMIN], domain=[uvic.ca], ...
>> 2024-04-11 23:40:23,144 ERROR [
>> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - > SimplePrincipal(id=rbon, attributes={duoAud=[...],
>> duoAuthCtxAccessDeviceIp=[...], ...
>>
>> The principal id's are the same (so merging attributes should work).
>>
>> Our setup fetches attributes after authentication (instead of at the time
>> of authentication) but before duo flow.
>>
>> I will investigate if there is an effect of when ldap attributes are
>> retrieved; as well as look into other possible config settings that might
>> affect attribute merging.
>>
>> Ray
>>
>>
>> On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
>>
>> Notice: This message was sent from outside the University of Victoria
>> email system. Please be cautious with links and sensitive information.
>>
>>
>> (Apologies for the repost. The CAS version has been added in the subject
>> line as well as the cas.properties file)
>>
>> We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The
>> system is configured to use OpenLDAP for authentication. However, once DUO
>> MFA is enabled via the Fawnoos blog entry, the attributes returned for the
>> principal are from DUO.
>>
>> How do we tell CAS to only use the LDAP attribute repository?
>>
>> Thanks,
>> Mike
>>
>> *cas.properties*
>>
>> cas.server.name=https://cas-poc.xxx.yyy
>> cas.server.prefix=${cas.server.name}/cas
>> cas.server.scope=xxx.yyy
>> cas.host.name=xxx.yyy
>>
>> logging.config: file:/etc/cas/config/log4j2.xml
>> logging.level.org.apereoi.cas=debug
>>
>> server.port=8443
>> server.ssl.enabled=true
>> server.ssl.protocol=TLS
>> server.ssl.key-store=file:/etc/cas/config/keystore.jks
>> server.ssl.key-store-password=XXX
>> server.ssl.key-password=Y
>> server.ssl.key-store-type=JKS
>> server.ssl.key-alias=default
>>
>> server.servlet.context-path=/cas
>> server.servlet.application-display-name=cas
>>
>> cas.server.tomcat.http[0].enabled=false
>> cas.server.tomcat.http-proxy.enabled=true
>> cas.server.tomcat.http-proxy.secure=false
>> cas.server.tomcat.http-proxy.scheme=https
>> cas.server.tomcat.http-proxy.pr
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
I created, https://github.com/apereo/cas/pull/6019 as a fix for this.
If you can not wait for the changes to be in mainstream cas, you can copy in
the modified files to your overlay.
Ray
On Wed, 2024-04-17 at 06:03 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and sensitive information.
You're right! Removing support-surrogate-webflow allows merging to proceed
properly. Think this will be addressed in 7.1, or is this working as intended
and we have to do something else to enable proper attribute merging?
On Tuesday, April 16, 2024 at 8:55:32 p.m. UTC-2:30 Ray Bon wrote:
I have been able to confirm that the presence of the surrogate log in feature
can create the observed problem.
implementation "org.apereo.cas:cas-server-support-surrogate-webflow"
The non merging of attributes happens even though no surrogate login takes
place.
Ray
On Mon, 2024-04-15 at 12:30 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and sensitive information.
FYI, downgrading to 6.6.13 works. DUO universal prompt functions properly and
the principal attributes are from LDAP only. I'm suspicious that something
about DUO and/or MFA is broken in CAS 7.0.3.
On Monday, April 15, 2024 at 2:10:54 p.m. UTC-2:30 Mike S wrote:
Hi Ray,
it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:
/var/log/cas
debug
On Saturday, April 13, 2024 at 1:48:06 a.m. UTC-2:30 Ray Bon wrote:
Mike,
What logger did you enable to see this?
Ray
On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and sensitive information.
Thanks for your response Ray. I've been banging my head against this for a
while and I thought it was something I was missing. I've verified the conflict
resolver option doesn't work.
The log debug log output shows the LDAP and DUO attributes at one point are
merged, but the result is discarded.
Is there a suggested workaround?
On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
Mike,
I can confirm this behaviour.
DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The change
was in 5bcef20 about 5 months ago.
The old behaviour was to select the first principle in a list; new behaviour
defaults to last.
Even setting this property,
cas.person-directory.principal-resolution-conflict-strategy=first
does not work.
Printing the list of principals immediately before
PrincipalElectionStrategyConflictResolver is invoked:
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - http://uvic.ca>], ...
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - http://cas.server.name>=https://cas-poc.xxx.yyy
cas.server.prefix=${cas.server.name}/cas
cas.server.scope=xxx.yyy
cas.host.name=xxx.yyy
logging.config: file:/etc/cas/config/log4j2.xml
logging.level.org.apereoi.cas=debug
server.port=8443
server.ssl.enabled=true
server.ssl.protocol=TLS
server.ssl.key-store=file:/etc/cas/config/keystore.jks
server.ssl.key-store-password=XXX
server.ssl.key-password=Y
server.ssl.key-store-type=JKS
server.ssl.key-alias=default
server.servlet.context-path=/cas
server.servlet.application-display-name=cas
cas.server.tomcat.http[0].enabled=false
cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.secure=false
cas.server.tomcat.http-proxy.scheme=https
cas.server.tomcat.http-proxy.protocol=HTTP/2
server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
server.tomcat.accesslog.request-attributes-enabled=true
server.tomcat.max-http-form-post-size=2097152
server.tomcat.max-threads=200
[service registry config omitted]
cas.authn.accept.users=
cas.authn.accept.enabled=false
cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
cas.authn.ldap[0].bind-credential=XX
cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
cas.authn.mfa.duo[0].account-status-enabled=true
cas.authn.mfa.duo[0].duo-secret-key=XX
cas.authn.mfa.duo[0].duo-integration-key=Y
cas.authn.mfa.duo[0].duo-api-host=ZZ
--
- 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 Group
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
You're right! Removing support-surrogate-webflow allows merging to proceed
properly. Think this will be addressed in 7.1, or is this working as
intended and we have to do something else to enable proper attribute
merging?
On Tuesday, April 16, 2024 at 8:55:32 p.m. UTC-2:30 Ray Bon wrote:
> I have been able to confirm that the presence of the surrogate log in
> feature can create the observed problem.
>
> implementation "org.apereo.cas:cas-server-support-surrogate-webflow"
>
> The non merging of attributes happens even though no surrogate login takes
> place.
>
> Ray
>
> On Mon, 2024-04-15 at 12:30 -0700, Mike S wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
> FYI, downgrading to 6.6.13 works. DUO universal prompt functions properly
> and the principal attributes are from LDAP only. I'm suspicious that
> something about DUO and/or MFA is broken in CAS 7.0.3.
>
> On Monday, April 15, 2024 at 2:10:54 p.m. UTC-2:30 Mike S wrote:
>
> Hi Ray,
>
> it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:
>
>
>
> /var/log/cas
> *debug*
>
> On Saturday, April 13, 2024 at 1:48:06 a.m. UTC-2:30 Ray Bon wrote:
>
> Mike,
>
> What logger did you enable to see this?
>
> Ray
>
> On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
> Thanks for your response Ray. I've been banging my head against this for a
> while and I thought it was something I was missing. I've verified the
> conflict resolver option doesn't work.
>
> The log debug log output shows the LDAP and DUO attributes at one point
> are merged, but the result is discarded.
>
> Is there a suggested workaround?
>
> On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
>
> Mike,
>
> I can confirm this behaviour.
> DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The
> change was in 5bcef20 about 5 months ago.
>
> The old behaviour was to select the first principle in a list; new
> behaviour defaults to last.
> Even setting this property,
>
> cas.person-directory.principal-resolution-conflict-strategy=first
>
> does not work.
>
> Printing the list of principals immediately before
> PrincipalElectionStrategyConflictResolver is invoked:
>
> 2024-04-11 23:40:23,144 ERROR [
> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - SimplePrincipal(id=rbon, attributes={cn=[Ray Bon],
> description=[ROLE_ADMIN], domain=[uvic.ca], ...
> 2024-04-11 23:40:23,144 ERROR [
> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - SimplePrincipal(id=rbon, attributes={duoAud=[...],
> duoAuthCtxAccessDeviceIp=[...], ...
>
> The principal id's are the same (so merging attributes should work).
>
> Our setup fetches attributes after authentication (instead of at the time
> of authentication) but before duo flow.
>
> I will investigate if there is an effect of when ldap attributes are
> retrieved; as well as look into other possible config settings that might
> affect attribute merging.
>
> Ray
>
>
> On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
>
> (Apologies for the repost. The CAS version has been added in the subject
> line as well as the cas.properties file)
>
> We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The
> system is configured to use OpenLDAP for authentication. However, once DUO
> MFA is enabled via the Fawnoos blog entry, the attributes returned for the
> principal are from DUO.
>
> How do we tell CAS to only use the LDAP attribute repository?
>
> Thanks,
> Mike
>
> *cas.properties*
>
> cas.server.name=https://cas-poc.xxx.yyy
> cas.server.prefix=${cas.server.name}/cas
> cas.server.scope=xxx.yyy
> cas.host.name=xxx.yyy
>
> logging.config: file:/etc/cas/config/log4j2.xml
> logging.level.org.apereoi.cas=debug
>
> server.port=8443
> server.ssl.enabled=true
> server.ssl.protocol=TLS
> server.ssl.key-store=file:/etc/cas/config/keystore.jks
> server.ssl.key-store-password=XXX
> server.ssl.key-password=Y
> server.ssl.key-store-type=JKS
> server.ssl.key-alias=default
>
> server.servlet.context-path=/cas
> server.servlet.application-display-name=cas
>
> cas.server.tomcat.http[0].enabled=false
> cas.server.tomcat.http-proxy.enabled=true
> cas.server.tomcat.http-proxy.secure=false
> cas.server.tomcat.http-proxy.scheme=https
> cas.server.tomcat.http-proxy.protocol=HTTP/2
> server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
> server.tomcat.accesslog.request-attributes-enabled=true
> server.tomcat.max-http-form-post-size=2097152
> server.tomcat.max-threads=200
>
> [service registry config omitted]
>
> cas.authn.accept.users=
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
I have been able to confirm that the presence of the surrogate log in feature
can create the observed problem.
implementation "org.apereo.cas:cas-server-support-surrogate-webflow"
The non merging of attributes happens even though no surrogate login takes
place.
Ray
On Mon, 2024-04-15 at 12:30 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and sensitive information.
FYI, downgrading to 6.6.13 works. DUO universal prompt functions properly and
the principal attributes are from LDAP only. I'm suspicious that something
about DUO and/or MFA is broken in CAS 7.0.3.
On Monday, April 15, 2024 at 2:10:54 p.m. UTC-2:30 Mike S wrote:
Hi Ray,
it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:
/var/log/cas
debug
On Saturday, April 13, 2024 at 1:48:06 a.m. UTC-2:30 Ray Bon wrote:
Mike,
What logger did you enable to see this?
Ray
On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and sensitive information.
Thanks for your response Ray. I've been banging my head against this for a
while and I thought it was something I was missing. I've verified the conflict
resolver option doesn't work.
The log debug log output shows the LDAP and DUO attributes at one point are
merged, but the result is discarded.
Is there a suggested workaround?
On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
Mike,
I can confirm this behaviour.
DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The change
was in 5bcef20 about 5 months ago.
The old behaviour was to select the first principle in a list; new behaviour
defaults to last.
Even setting this property,
cas.person-directory.principal-resolution-conflict-strategy=first
does not work.
Printing the list of principals immediately before
PrincipalElectionStrategyConflictResolver is invoked:
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - http://uvic.ca>], ...
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - http://cas.server.name>=https://cas-poc.xxx.yyy
cas.server.prefix=${cas.server.name}/cas
cas.server.scope=xxx.yyy
cas.host.name=xxx.yyy
logging.config: file:/etc/cas/config/log4j2.xml
logging.level.org.apereoi.cas=debug
server.port=8443
server.ssl.enabled=true
server.ssl.protocol=TLS
server.ssl.key-store=file:/etc/cas/config/keystore.jks
server.ssl.key-store-password=XXX
server.ssl.key-password=Y
server.ssl.key-store-type=JKS
server.ssl.key-alias=default
server.servlet.context-path=/cas
server.servlet.application-display-name=cas
cas.server.tomcat.http[0].enabled=false
cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.secure=false
cas.server.tomcat.http-proxy.scheme=https
cas.server.tomcat.http-proxy.protocol=HTTP/2
server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
server.tomcat.accesslog.request-attributes-enabled=true
server.tomcat.max-http-form-post-size=2097152
server.tomcat.max-threads=200
[service registry config omitted]
cas.authn.accept.users=
cas.authn.accept.enabled=false
cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
cas.authn.ldap[0].bind-credential=XX
cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
cas.authn.mfa.duo[0].account-status-enabled=true
cas.authn.mfa.duo[0].duo-secret-key=XX
cas.authn.mfa.duo[0].duo-integration-key=Y
cas.authn.mfa.duo[0].duo-api-host=ZZ
--
- 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/6a5e43ae49cf05c078ac3ea2b3f6b451dd779e0f.camel%40uvic.ca.
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
FYI, downgrading to 6.6.13 works. DUO universal prompt functions properly
and the principal attributes are from LDAP only. I'm suspicious that
something about DUO and/or MFA is broken in CAS 7.0.3.
On Monday, April 15, 2024 at 2:10:54 p.m. UTC-2:30 Mike S wrote:
> Hi Ray,
>
> it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:
>
>
>
> /var/log/cas
> *debug*
>
> On Saturday, April 13, 2024 at 1:48:06 a.m. UTC-2:30 Ray Bon wrote:
>
>> Mike,
>>
>> What logger did you enable to see this?
>>
>> Ray
>>
>> On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
>>
>> Notice: This message was sent from outside the University of Victoria
>> email system. Please be cautious with links and sensitive information.
>>
>> Thanks for your response Ray. I've been banging my head against this for
>> a while and I thought it was something I was missing. I've verified the
>> conflict resolver option doesn't work.
>>
>> The log debug log output shows the LDAP and DUO attributes at one point
>> are merged, but the result is discarded.
>>
>> Is there a suggested workaround?
>>
>> On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
>>
>> Mike,
>>
>> I can confirm this behaviour.
>> DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The
>> change was in 5bcef20 about 5 months ago.
>>
>> The old behaviour was to select the first principle in a list; new
>> behaviour defaults to last.
>> Even setting this property,
>>
>> cas.person-directory.principal-resolution-conflict-strategy=first
>>
>> does not work.
>>
>> Printing the list of principals immediately before
>> PrincipalElectionStrategyConflictResolver is invoked:
>>
>> 2024-04-11 23:40:23,144 ERROR [
>> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - > SimplePrincipal(id=rbon, attributes={cn=[Ray Bon],
>> description=[ROLE_ADMIN], domain=[uvic.ca], ...
>> 2024-04-11 23:40:23,144 ERROR [
>> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - > SimplePrincipal(id=rbon, attributes={duoAud=[...],
>> duoAuthCtxAccessDeviceIp=[...], ...
>>
>> The principal id's are the same (so merging attributes should work).
>>
>> Our setup fetches attributes after authentication (instead of at the time
>> of authentication) but before duo flow.
>>
>> I will investigate if there is an effect of when ldap attributes are
>> retrieved; as well as look into other possible config settings that might
>> affect attribute merging.
>>
>> Ray
>>
>>
>> On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
>>
>> Notice: This message was sent from outside the University of Victoria
>> email system. Please be cautious with links and sensitive information.
>>
>>
>> (Apologies for the repost. The CAS version has been added in the subject
>> line as well as the cas.properties file)
>>
>> We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The
>> system is configured to use OpenLDAP for authentication. However, once DUO
>> MFA is enabled via the Fawnoos blog entry, the attributes returned for the
>> principal are from DUO.
>>
>> How do we tell CAS to only use the LDAP attribute repository?
>>
>> Thanks,
>> Mike
>>
>> *cas.properties*
>>
>> cas.server.name=https://cas-poc.xxx.yyy
>> cas.server.prefix=${cas.server.name}/cas
>> cas.server.scope=xxx.yyy
>> cas.host.name=xxx.yyy
>>
>> logging.config: file:/etc/cas/config/log4j2.xml
>> logging.level.org.apereoi.cas=debug
>>
>> server.port=8443
>> server.ssl.enabled=true
>> server.ssl.protocol=TLS
>> server.ssl.key-store=file:/etc/cas/config/keystore.jks
>> server.ssl.key-store-password=XXX
>> server.ssl.key-password=Y
>> server.ssl.key-store-type=JKS
>> server.ssl.key-alias=default
>>
>> server.servlet.context-path=/cas
>> server.servlet.application-display-name=cas
>>
>> cas.server.tomcat.http[0].enabled=false
>> cas.server.tomcat.http-proxy.enabled=true
>> cas.server.tomcat.http-proxy.secure=false
>> cas.server.tomcat.http-proxy.scheme=https
>> cas.server.tomcat.http-proxy.protocol=HTTP/2
>> server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
>> server.tomcat.accesslog.request-attributes-enabled=true
>> server.tomcat.max-http-form-post-size=2097152
>> server.tomcat.max-threads=200
>>
>> [service registry config omitted]
>>
>> cas.authn.accept.users=
>> cas.authn.accept.enabled=false
>>
>> cas.authn.ldap[0].type=AUTHENTICATED
>> cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
>> cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
>> cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
>> cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
>> cas.authn.ldap[0].bind-credential=XX
>>
>> cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
>>
>> cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
>> cas.authn.mfa.duo[0].account-status-enabled=true
>> cas.authn.mfa.duo[0].duo-secret-key=XX
>> cas.
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
Hi Ray,
it was in /etc/cas/config/lob4j2.xml, setting the log level to debug:
/var/log/cas
*debug*
On Saturday, April 13, 2024 at 1:48:06 a.m. UTC-2:30 Ray Bon wrote:
> Mike,
>
> What logger did you enable to see this?
>
> Ray
>
> On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
> Thanks for your response Ray. I've been banging my head against this for a
> while and I thought it was something I was missing. I've verified the
> conflict resolver option doesn't work.
>
> The log debug log output shows the LDAP and DUO attributes at one point
> are merged, but the result is discarded.
>
> Is there a suggested workaround?
>
> On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
>
> Mike,
>
> I can confirm this behaviour.
> DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The
> change was in 5bcef20 about 5 months ago.
>
> The old behaviour was to select the first principle in a list; new
> behaviour defaults to last.
> Even setting this property,
>
> cas.person-directory.principal-resolution-conflict-strategy=first
>
> does not work.
>
> Printing the list of principals immediately before
> PrincipalElectionStrategyConflictResolver is invoked:
>
> 2024-04-11 23:40:23,144 ERROR [
> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - SimplePrincipal(id=rbon, attributes={cn=[Ray Bon],
> description=[ROLE_ADMIN], domain=[uvic.ca], ...
> 2024-04-11 23:40:23,144 ERROR [
> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - SimplePrincipal(id=rbon, attributes={duoAud=[...],
> duoAuthCtxAccessDeviceIp=[...], ...
>
> The principal id's are the same (so merging attributes should work).
>
> Our setup fetches attributes after authentication (instead of at the time
> of authentication) but before duo flow.
>
> I will investigate if there is an effect of when ldap attributes are
> retrieved; as well as look into other possible config settings that might
> affect attribute merging.
>
> Ray
>
>
> On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
>
> (Apologies for the repost. The CAS version has been added in the subject
> line as well as the cas.properties file)
>
> We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The
> system is configured to use OpenLDAP for authentication. However, once DUO
> MFA is enabled via the Fawnoos blog entry, the attributes returned for the
> principal are from DUO.
>
> How do we tell CAS to only use the LDAP attribute repository?
>
> Thanks,
> Mike
>
> *cas.properties*
>
> cas.server.name=https://cas-poc.xxx.yyy
> cas.server.prefix=${cas.server.name}/cas
> cas.server.scope=xxx.yyy
> cas.host.name=xxx.yyy
>
> logging.config: file:/etc/cas/config/log4j2.xml
> logging.level.org.apereoi.cas=debug
>
> server.port=8443
> server.ssl.enabled=true
> server.ssl.protocol=TLS
> server.ssl.key-store=file:/etc/cas/config/keystore.jks
> server.ssl.key-store-password=XXX
> server.ssl.key-password=Y
> server.ssl.key-store-type=JKS
> server.ssl.key-alias=default
>
> server.servlet.context-path=/cas
> server.servlet.application-display-name=cas
>
> cas.server.tomcat.http[0].enabled=false
> cas.server.tomcat.http-proxy.enabled=true
> cas.server.tomcat.http-proxy.secure=false
> cas.server.tomcat.http-proxy.scheme=https
> cas.server.tomcat.http-proxy.protocol=HTTP/2
> server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
> server.tomcat.accesslog.request-attributes-enabled=true
> server.tomcat.max-http-form-post-size=2097152
> server.tomcat.max-threads=200
>
> [service registry config omitted]
>
> cas.authn.accept.users=
> cas.authn.accept.enabled=false
>
> cas.authn.ldap[0].type=AUTHENTICATED
> cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
> cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
> cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
> cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
> cas.authn.ldap[0].bind-credential=XX
>
> cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
>
> cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
> cas.authn.mfa.duo[0].account-status-enabled=true
> cas.authn.mfa.duo[0].duo-secret-key=XX
> cas.authn.mfa.duo[0].duo-integration-key=Y
> cas.authn.mfa.duo[0].duo-api-host=ZZ
>
>
>
>
--
- 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 f
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
Hi,
We are using CAS in version 6.5 on production with protocols OAuth, SAML,
OIDC. We use attributeRepository from LDAP because we need *memberOf *with
recursive data. There are many memberOf so we need to filter it out. We use
attributeReleasePolicy
with RegisteredServiceMutantRegexAttributeFilter. And on version 6.5 it
works*. *
We upgraded to version 7.0.3 and now resolving attributes is working very
bad. In OAuth 2.0 protocol we get all values from memberOf without
filtering. In SAML protocol it works good.
I've checked and ChainingAttributeReleasePolicy is returning good result.
But like Mike S sad this values are merged (all attributes + that filtered
out).
pt., 12 kwi 2024 o 20:40 Mike S napisał(a):
> Thanks for your response Ray. I've been banging my head against this for a
> while and I thought it was something I was missing. I've verified the
> conflict resolver option doesn't work.
>
> The log debug log output shows the LDAP and DUO attributes at one point
> are merged, but the result is discarded.
>
> Is there a suggested workaround?
>
> On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
>
>> Mike,
>>
>> I can confirm this behaviour.
>> DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The
>> change was in 5bcef20 about 5 months ago.
>>
>> The old behaviour was to select the first principle in a list; new
>> behaviour defaults to last.
>> Even setting this property,
>>
>> cas.person-directory.principal-resolution-conflict-strategy=first
>>
>> does not work.
>>
>> Printing the list of principals immediately before
>> PrincipalElectionStrategyConflictResolver is invoked:
>>
>> 2024-04-11 23:40:23,144 ERROR [
>> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - > SimplePrincipal(id=rbon, attributes={cn=[Ray Bon],
>> description=[ROLE_ADMIN], domain=[uvic.ca], ...
>> 2024-04-11 23:40:23,144 ERROR [
>> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - > SimplePrincipal(id=rbon, attributes={duoAud=[...],
>> duoAuthCtxAccessDeviceIp=[...], ...
>>
>> The principal id's are the same (so merging attributes should work).
>>
>> Our setup fetches attributes after authentication (instead of at the time
>> of authentication) but before duo flow.
>>
>> I will investigate if there is an effect of when ldap attributes are
>> retrieved; as well as look into other possible config settings that might
>> affect attribute merging.
>>
>> Ray
>>
>>
>> On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
>>
>> Notice: This message was sent from outside the University of Victoria
>> email system. Please be cautious with links and sensitive information.
>>
>>
>> (Apologies for the repost. The CAS version has been added in the subject
>> line as well as the cas.properties file)
>>
>> We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The
>> system is configured to use OpenLDAP for authentication. However, once DUO
>> MFA is enabled via the Fawnoos blog entry, the attributes returned for the
>> principal are from DUO.
>>
>> How do we tell CAS to only use the LDAP attribute repository?
>>
>> Thanks,
>> Mike
>>
>> *cas.properties*
>>
>> cas.server.name=https://cas-poc.xxx.yyy
>> cas.server.prefix=${cas.server.name}/cas
>> cas.server.scope=xxx.yyy
>> cas.host.name=xxx.yyy
>>
>> logging.config: file:/etc/cas/config/log4j2.xml
>> logging.level.org.apereoi.cas=debug
>>
>> server.port=8443
>> server.ssl.enabled=true
>> server.ssl.protocol=TLS
>> server.ssl.key-store=file:/etc/cas/config/keystore.jks
>> server.ssl.key-store-password=XXX
>> server.ssl.key-password=Y
>> server.ssl.key-store-type=JKS
>> server.ssl.key-alias=default
>>
>> server.servlet.context-path=/cas
>> server.servlet.application-display-name=cas
>>
>> cas.server.tomcat.http[0].enabled=false
>> cas.server.tomcat.http-proxy.enabled=true
>> cas.server.tomcat.http-proxy.secure=false
>> cas.server.tomcat.http-proxy.scheme=https
>> cas.server.tomcat.http-proxy.protocol=HTTP/2
>> server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
>> server.tomcat.accesslog.request-attributes-enabled=true
>> server.tomcat.max-http-form-post-size=2097152
>> server.tomcat.max-threads=200
>>
>> [service registry config omitted]
>>
>> cas.authn.accept.users=
>> cas.authn.accept.enabled=false
>>
>> cas.authn.ldap[0].type=AUTHENTICATED
>> cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
>> cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
>> cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
>> cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
>> cas.authn.ldap[0].bind-credential=XX
>>
>> cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
>>
>> cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
>> cas.authn.mfa.duo[0].account-status-enabled=true
>> cas.authn.mfa.duo[0].duo-secret-key=XX
>> cas.authn.mfa.duo[0].duo-integration-key=Y
>>
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
Mike,
What logger did you enable to see this?
Ray
On Fri, 2024-04-12 at 11:36 -0700, Mike S wrote:
Notice: This message was sent from outside the University of Victoria email
system. Please be cautious with links and sensitive information.
Thanks for your response Ray. I've been banging my head against this for a
while and I thought it was something I was missing. I've verified the conflict
resolver option doesn't work.
The log debug log output shows the LDAP and DUO attributes at one point are
merged, but the result is discarded.
Is there a suggested workaround?
On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
Mike,
I can confirm this behaviour.
DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The change
was in 5bcef20 about 5 months ago.
The old behaviour was to select the first principle in a list; new behaviour
defaults to last.
Even setting this property,
cas.person-directory.principal-resolution-conflict-strategy=first
does not work.
Printing the list of principals immediately before
PrincipalElectionStrategyConflictResolver is invoked:
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - http://uvic.ca>], ...
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - http://cas.server.name>=https://cas-poc.xxx.yyy
cas.server.prefix=${cas.server.name}/cas
cas.server.scope=xxx.yyy
cas.host.name=xxx.yyy
logging.config: file:/etc/cas/config/log4j2.xml
logging.level.org.apereoi.cas=debug
server.port=8443
server.ssl.enabled=true
server.ssl.protocol=TLS
server.ssl.key-store=file:/etc/cas/config/keystore.jks
server.ssl.key-store-password=XXX
server.ssl.key-password=Y
server.ssl.key-store-type=JKS
server.ssl.key-alias=default
server.servlet.context-path=/cas
server.servlet.application-display-name=cas
cas.server.tomcat.http[0].enabled=false
cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.secure=false
cas.server.tomcat.http-proxy.scheme=https
cas.server.tomcat.http-proxy.protocol=HTTP/2
server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
server.tomcat.accesslog.request-attributes-enabled=true
server.tomcat.max-http-form-post-size=2097152
server.tomcat.max-threads=200
[service registry config omitted]
cas.authn.accept.users=
cas.authn.accept.enabled=false
cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
cas.authn.ldap[0].bind-credential=XX
cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
cas.authn.mfa.duo[0].account-status-enabled=true
cas.authn.mfa.duo[0].duo-secret-key=XX
cas.authn.mfa.duo[0].duo-integration-key=Y
cas.authn.mfa.duo[0].duo-api-host=ZZ
--
- 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/f985f384c9f6a81b32a5ad83d8e160ac646f4e0e.camel%40uvic.ca.
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
Thanks for your response Ray. I've been banging my head against this for a
while and I thought it was something I was missing. I've verified the
conflict resolver option doesn't work.
The log debug log output shows the LDAP and DUO attributes at one point
are merged, but the result is discarded.
Is there a suggested workaround?
On Friday, April 12, 2024 at 12:24:47 p.m. UTC-2:30 Ray Bon wrote:
> Mike,
>
> I can confirm this behaviour.
> DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The
> change was in 5bcef20 about 5 months ago.
>
> The old behaviour was to select the first principle in a list; new
> behaviour defaults to last.
> Even setting this property,
>
> cas.person-directory.principal-resolution-conflict-strategy=first
>
> does not work.
>
> Printing the list of principals immediately before
> PrincipalElectionStrategyConflictResolver is invoked:
>
> 2024-04-11 23:40:23,144 ERROR [
> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - SimplePrincipal(id=rbon, attributes={cn=[Ray Bon],
> description=[ROLE_ADMIN], domain=[uvic.ca], ...
> 2024-04-11 23:40:23,144 ERROR [
> org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - SimplePrincipal(id=rbon, attributes={duoAud=[...],
> duoAuthCtxAccessDeviceIp=[...], ...
>
> The principal id's are the same (so merging attributes should work).
>
> Our setup fetches attributes after authentication (instead of at the time
> of authentication) but before duo flow.
>
> I will investigate if there is an effect of when ldap attributes are
> retrieved; as well as look into other possible config settings that might
> affect attribute merging.
>
> Ray
>
>
> On Wed, 2024-04-10 at 12:47 -0700, Mike S wrote:
>
> Notice: This message was sent from outside the University of Victoria
> email system. Please be cautious with links and sensitive information.
>
>
> (Apologies for the repost. The CAS version has been added in the subject
> line as well as the cas.properties file)
>
> We are testing a CAS 7.0.3 POC system using universal prompt DUO MFA. The
> system is configured to use OpenLDAP for authentication. However, once DUO
> MFA is enabled via the Fawnoos blog entry, the attributes returned for the
> principal are from DUO.
>
> How do we tell CAS to only use the LDAP attribute repository?
>
> Thanks,
> Mike
>
> *cas.properties*
>
> cas.server.name=https://cas-poc.xxx.yyy
> cas.server.prefix=${cas.server.name}/cas
> cas.server.scope=xxx.yyy
> cas.host.name=xxx.yyy
>
> logging.config: file:/etc/cas/config/log4j2.xml
> logging.level.org.apereoi.cas=debug
>
> server.port=8443
> server.ssl.enabled=true
> server.ssl.protocol=TLS
> server.ssl.key-store=file:/etc/cas/config/keystore.jks
> server.ssl.key-store-password=XXX
> server.ssl.key-password=Y
> server.ssl.key-store-type=JKS
> server.ssl.key-alias=default
>
> server.servlet.context-path=/cas
> server.servlet.application-display-name=cas
>
> cas.server.tomcat.http[0].enabled=false
> cas.server.tomcat.http-proxy.enabled=true
> cas.server.tomcat.http-proxy.secure=false
> cas.server.tomcat.http-proxy.scheme=https
> cas.server.tomcat.http-proxy.protocol=HTTP/2
> server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
> server.tomcat.accesslog.request-attributes-enabled=true
> server.tomcat.max-http-form-post-size=2097152
> server.tomcat.max-threads=200
>
> [service registry config omitted]
>
> cas.authn.accept.users=
> cas.authn.accept.enabled=false
>
> cas.authn.ldap[0].type=AUTHENTICATED
> cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
> cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
> cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
> cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
> cas.authn.ldap[0].bind-credential=XX
>
> cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
>
> cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
> cas.authn.mfa.duo[0].account-status-enabled=true
> cas.authn.mfa.duo[0].duo-secret-key=XX
> cas.authn.mfa.duo[0].duo-integration-key=Y
> cas.authn.mfa.duo[0].duo-api-host=ZZ
>
>
--
- 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/b07dcb6c-4c61-4823-9822-1efb0ad53c78n%40apereo.org.
Re: [cas-user] CAS 7.0.3: missing LDAP principal attributes when using DUO MFA
Mike,
I can confirm this behaviour.
DefaultPrincipalElectionStrategy was changed between 6.5 and 7.0. The change
was in 5bcef20 about 5 months ago.
The old behaviour was to select the first principle in a list; new behaviour
defaults to last.
Even setting this property,
cas.person-directory.principal-resolution-conflict-strategy=first
does not work.
Printing the list of principals immediately before
PrincipalElectionStrategyConflictResolver is invoked:
2024-04-11 23:40:23,144 ERROR [
org.aper.cas.auth.prin.DefaultPrincipalElectionStrategy] - https://cas-poc.xxx.yyy
cas.server.prefix=${cas.server.name}/cas
cas.server.scope=xxx.yyy
cas.host.name=xxx.yyy
logging.config: file:/etc/cas/config/log4j2.xml
logging.level.org.apereoi.cas=debug
server.port=8443
server.ssl.enabled=true
server.ssl.protocol=TLS
server.ssl.key-store=file:/etc/cas/config/keystore.jks
server.ssl.key-store-password=XXX
server.ssl.key-password=Y
server.ssl.key-store-type=JKS
server.ssl.key-alias=default
server.servlet.context-path=/cas
server.servlet.application-display-name=cas
cas.server.tomcat.http[0].enabled=false
cas.server.tomcat.http-proxy.enabled=true
cas.server.tomcat.http-proxy.secure=false
cas.server.tomcat.http-proxy.scheme=https
cas.server.tomcat.http-proxy.protocol=HTTP/2
server.tomcat.remoteip.internal-proxies=AAA.BBB.CCC.DDD
server.tomcat.accesslog.request-attributes-enabled=true
server.tomcat.max-http-form-post-size=2097152
server.tomcat.max-threads=200
[service registry config omitted]
cas.authn.accept.users=
cas.authn.accept.enabled=false
cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].ldap-url=ldaps://ldap1.xxx.yyy,ldaps://ldap2.xxx.yyy
cas.authn.ldap[0].base-dn=dc=xxx,dc=yyy
cas.authn.ldap[0].search-filter=(|(uid={user})(mailAddress={user}))
cas.authn.ldap[0].bind-dn=uid=ro-ldap-user,ou=users,dc=xxx,dc=yyy
cas.authn.ldap[0].bind-credential=XX
cas.authn.ldap[0].principal-attribute-list=altEmailaltEmailDate,authViaAltEmailVerificationKey,[...]
cas.authn.mfa.triggers.global.global-provider-id=mfa-duo
cas.authn.mfa.duo[0].account-status-enabled=true
cas.authn.mfa.duo[0].duo-secret-key=XX
cas.authn.mfa.duo[0].duo-integration-key=Y
cas.authn.mfa.duo[0].duo-api-host=ZZ
--
- 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/be817c555ca880dbf6d5bce10c23f387bcd34997.camel%40uvic.ca.
