Try authenticated type instead,
cas.authn.ldap[0].type=AUTHENTICATED
cas.authn.ldap[0].bindDn=YOUR_BIND_DN, Can be upn format as well instead of
full dn
cas.authn.ldap[0].bindCredential=YOUR_BIND_PASSWORD
On Wednesday, June 21, 2023 at 9:42:15 AM UTC-5 Ray Bon wrote:
> Jérémie,
>
> 'Unknown u
v6.6.6 is valid, it is a security release,
https://apereo.github.io/2023/02/20/x509-vuln/
On Monday, March 6, 2023 at 11:13:04 PM UTC-6 jonan...@oru.edu wrote:
> https://casinit.herokuapp.com/actuator/supportedVersions 6.6.6
>
> https://github.com/apereo/cas/tags 6.6.5
>
> Am I missing somethi
I was able to get it working on 6.6.x by adding a version override in
build.gradle within the configurations.all section, dropping version to
2.4.1
eachDependency { DependencyResolveDetails details ->
def requested = details.requested
if (requested.group == "org.a
although its a bit sluggish, web archive has it, it's also on github source
code under docs if you want to build it, this has 4.x up to 6.3 using the date
I randomly chose,
https://web.archive.org/web/20210616111636/https://apereo.github.io/cas/5.0.x/
From: cas-u
You can use cas.authn.pm.ldap[0].searchFilter , just make sure you set
others
required,
https://apereo.github.io/cas/6.5.x/password_management/Password-Management-LDAP.html
, something like the below would work, msds-parentname is a constructed
attribute in AD that holds the value of the curr
We are using JSON format so that its more Filebeat friendly, did you also configure in your cas.properties? We didn’t have to change anything in the log4j xml besides enabling the audit file, the properties are below which comes from https://apereo.github.io/cas/6.2.x/configuration/Configuration-Pr
Are you sure, looks to me you have a typo in your ldap config, you have, dc=ou=people,example,dc=org, notice the dc= before ou= cas.authn.ldap[0].base-dn=dc=ou=people,exemple,dc=org But then you have cas.authn.ldap[0].dn-format=uid=%s,ou=people,dc=exemple,dc=org From: qla3faSent: Wednesday, August
you could also just use a few lines of javascript on your login page to first
convert the username input to lowercase before posting, easier then messing
with your db if it is used for some other applications
From: cas-user@apereo.org on behalf of Kink
Sent: F
the superset of
attributes that may be released. The service registry json defines the
attributes (subset) allowed to be released to the service?
-Bryan
On Mon, Jun 15, 2020 at 3:08 PM Jason Everling
mailto:jason.everl...@gmail.com>> wrote:
I didnt think CAS pulls attributes from ldap ba
I didnt think CAS pulls attributes from ldap based on the service
definition? You have to add all attributes you expect to fetch from ldap,
so in your config
cas.authn.ldap[0].principalAttributeList=unid,cn,psrole,mail,uuemployee,uustudent,uuaffiliate,uudept,almail,sn,givenName
Change it to
cas.
probably don’t need to be a developer. A containerized app with
> some external configuration is not unheard of :-)
>
> On May 17, 2020, at 6:45 PM, Jason Everling > wrote:
>
> It much easier, development wise, to use IntelliJ Idea to prepare and
> deploy CAS,
It much easier, development wise, to use IntelliJ Idea to prepare and
deploy CAS, you could also probably use Eclipse
--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
Yo
e
> SAML1 so had to back track and move to the unicorn shib-cas plugin with CAS
> 6.1.4.
>
> If you only need SAML2 then CAS Shib works fine, but for SAML1 as well,
> you still need to use shibboleth.
>
>
> On Thursday, April 9, 2020 at 8:26:19 PM UTC+1, Jason Everling wr
Has anyone moved from standalone Shib to the built-in CAS Shib? I am
looking to migrate ours, reduce complexity in our sso environment, we never
really used Shib as a login source, CAS was always redirected to by Shib
and I am curious on how you handled the new deployment. Did you just update
D
I never knew this was added to cas, I somehow stumbled upon it after
looking over an updated default application.properties, it essentially adds
the attribute release to the 2.0 protocol. I was still using a modded 2.0
view and the later started using the method described here,
https://groups.g
I was able to use the cas rest password management feature to do what I
needed, I created a simple api to translate what cas sends to what my app
is expecting, so basically it sends the rest request to my script which in
turn translates it and sends it to our password management app.
--
- Webs
Is there a way to change the ldap password policy, for example, what I
would like to do,
When Must Change Password or Password Expired detected, allow the login
instead of blocking, grant service ticket/tgt , as if no errors occurred so
that I can redirect the user to our password management ap
at 8:25 AM Robert Bond
mailto:bo...@nsuok.edu>> wrote:
iirc it can be the root ca or the client public cert.
Are you using a public ca, and if so which one?
To be safe you could just put the fullchain.
On Thu, Feb 20, 2020 at 8:06 PM Jason Everling
mailto:jason.everl...@gmail.com>> wr
ificates=file:/etc/cas/ldaps_cert.crt
>
> On Wed, Feb 19, 2020 at 7:34 PM Jason Everling
> wrote:
>
>> Grab your LDAPS certificates, create a new JKS keystore type and add your
>> certificates to it. The default java password is changeit so we will just
>
I fixed it, seems I had support-pm-jdbc in my pom, removed, cleaned, and
deployed, works fine now.
--
- 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 mes
Yes, I am leaving at AD for type in passwordPolicy and running tests, AD is
also required for cas.authn.pm.ldap.type.
Although I can login now, when having to change password it errors with the
below but I am not using sql in any cases, anywhere, for CAS
2020-02-20 09:15:30,513 ERROR
[org.aper
It doesn't start, error message below. Also, I just realized it works under
the cas.authn.ldap[0].type BUT the one that causes it is
cas.authn.ldap[0].passwordPolicy.type=AUTHENTICATED
changing to
cas.authn.ldap[0].passwordPolicy.type=AD CAS starts up just fine.
When using AUTHENTICATED the e
Grab your LDAPS certificates, create a new JKS keystore type and add your
certificates to it. The default java password is changeit so we will just
use that as well. The AD ldap settings would be,
cas.authn.ldap[0].keystore=file:/etc/cas/your_keystore_name
cas.authn.ldap[0].keystorePassword=chan
Looks like after a test upgrade from 6.0.x to
6.1.4 cas.authn.ldap[0].type=AUTHENTICATED no longer exists, it has to
use cas.authn.ldap[0].type=AD but logins DO NOT work using the AD type, it
never has. We have always had to use AUTHENTICATED but it looks like it was
removed?
Under
https://ap
24 matches
Mail list logo
