Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Thanks John,

I'll keep that in mind about the p3 endpoint when I get to the next step of
this project.

Mike

On Wed, Jul 1, 2015 at 8:52 AM, John Ryan  wrote:

>  Great to hear, Mike.
>
> A piece of advice for returning attributes: not sure if it is better
> documented now than when I was stumbling around with it, but make sure you
> call the p3 endpoint on service validation
> (.../cas/p3/serviceValidate?...).  This invokes the CAS 3.0 protocol, and
> works very, very well for returning attributes.
>
> John
> RedZone Software
>
> On 7/1/2015 8:46 AM, Mike Seiler wrote:
>
> Thank you all for your suggestions and help.  I touch CAS maybe once a
> year when changes are needed, so I'm not very savvy.
>
>  By setting the log values to TRACE I was able to determine that CAS was
> never initiating the ldap search (as Daniel pointed out) and figure out
> what was causing that.
>
>  The authentication *succeeded* after the following:
> 1) Using the 2nd option (LDAP Requiring Authenticated Search), and fixing
> differences in the sample code and my cas.properties file (e.g.
> ldap.managerDn vs ldap.authn.managerDn)
>  2) changing the the managerDN to the 
> admin_acco...@id.fuller.edu -- in the 3.5.2 installation, I used the full
> CN=CASADMIN, etc...
> 3) setting useStartTLS=false
> 4) setting searchFilter to (sAMAccountName={user}) -- anything else seems
> to fail
>
>  The response from the server (in catalina.out) contains all the
> attributes I'm hoping to get (and then some), so it seems that the
> attribute mapping is working as well.  I'll find out more when I modify the
> authorization plugins for our external apps to pull the CAS attributes list.
>
>  *SSL*
> It seems that disabling/enabling the sslConfig bean makes no difference in
> my config; the certs are stored in the default keystore as well, so both
> methods build and authenticate.
>
>  In the interest of helping fellow Google searchers down the road, I've
> attached my LDAP properties section of the cas.properties file below:
>
>  #
> # General properties
> #
> ldap.url=ldaps://id.fuller.edu
> # LDAP connection timeout in milliseconds
>  ldap.connectTimeout=3000
> # Whether to use StartTLS (probably needed if not SSL connection)
>  ldap.useStartTLS=false
> #
>  # LDAP connection pool configuration
> #
> ldap.pool.minSize=3
> ldap.pool.maxSize=10
> ldap.pool.validateOnCheckout=false
> ldap.pool.validatePeriodically=true
> ldap.pool.blockWaitTime=3000
>  ldap.pool.validatePeriod=300
>  ldap.pool.prunePeriod=300
>  ldap.pool.idleTime=600
>   #
> # Authentication
> #
> # Base DN of users to be authenticated
> ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
> # Manager DN for authenticated searches
> ldap.authn.managerDn=admin_acco...@id.fuller.edu
> # Manager password for authenticated searches
> ldap.authn.managerPassword=admin_password
> # Search filter used for configurations that require searching for DNs
> ldap.authn.searchFilter=(sAMAccountName={user})
> # Domain Setting
>  ldap.domain=fuller.edu
> ldap.trustedCert=file:/etc/cas/id_app.pem
>
>  and am attaching my current deployerConfigContext.xml file to this email.
>
>  Thanks again,
>
>  Mike
>
>
> On Tue, Jun 30, 2015 at 3:27 PM, Mike Seiler 
> wrote:
>
>> Thank you Mihai and John.
>>
>>  I will try those things first thing in the morning and get back to you
>> with all the additional logs and details.
>>
>>  Mike
>>
>> On Tue, Jun 30, 2015 at 3:22 PM, John Ryan < 
>> jr...@redzone.co> wrote:
>>
>>>  Mike,
>>>
>>> I think Daniel is on to something: we see no indication whatsoever in
>>> your log output that LDAP authentication is even being attempted.  In your
>>> log4j.xml please dial way back everything (most especially
>>> org.springframework) to WARN except org.jasig and org.ldaptive (set
>>> both to TRACE).  After you attempt to hit a CAS-ified application, we
>>> should then see a rich set of detail about CAS placing a service in
>>> FlowScope, generating a login ticket, etc.
>>>
>>> If everything is OK up to that point, we'll see an "Attempting LDAP
>>> authentication" message from
>>> org.jasig.cas.authentication.LdapAuthenticationHandler, followed by rich
>>> detail from org.ldaptive components as they interact with AD.
>>>
>>> FYI we're using CAS 4.0 with AD and it is working fine.  The only
>>> differences that jump out to me from our configuration is that we don't use
>>> any of the ldap.authn properties at all, as we want to use the user's
>>> sAMAccountName.
>>>
>>> Also, one departure from the deployerConfigContext.xml at
>>> 
>>> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
>>> is t

Re: [cas-user] Help with CAS 4.0 & AD

[John Ryan]

Great to hear, Mike.

A piece of advice for returning attributes: not sure if it is better 
documented now than when I was stumbling around with it, but make sure 
you call the p3 endpoint on service validation 
(.../cas/p3/serviceValidate?...).  This invokes the CAS 3.0 protocol, 
and works very, very well for returning attributes.

John
RedZone Software

On 7/1/2015 8:46 AM, Mike Seiler wrote:
> Thank you all for your suggestions and help.  I touch CAS maybe once a 
> year when changes are needed, so I'm not very savvy.
>
> By setting the log values to TRACE I was able to determine that CAS 
> was never initiating the ldap search (as Daniel pointed out) and 
> figure out what was causing that.
>
> The authentication /*succeeded*/ after the following:
> 1) Using the 2nd option (LDAP Requiring Authenticated Search), and 
> fixing differences in the sample code and my cas.properties file (e.g. 
> ldap.managerDn vs ldap.authn.managerDn)
> 2) changing the the managerDN to the admin_acco...@id.fuller.edu 
>  -- in the 3.5.2 installation, I 
> used the full CN=CASADMIN, etc...
> 3) setting useStartTLS=false
> 4) setting searchFilter to (sAMAccountName={user}) -- anything else 
> seems to fail
>
> The response from the server (in catalina.out) contains all the 
> attributes I'm hoping to get (and then some), so it seems that the 
> attribute mapping is working as well.  I'll find out more when I 
> modify the authorization plugins for our external apps to pull the CAS 
> attributes list.
>
> *SSL*
> It seems that disabling/enabling the sslConfig bean makes no 
> difference in my config; the certs are stored in the default keystore 
> as well, so both methods build and authenticate.
>
> In the interest of helping fellow Google searchers down the road, I've 
> attached my LDAP properties section of the cas.properties file below:
>
> #
> # General properties
> #
> ldap.url=ldaps://id.fuller.edu 
> # LDAP connection timeout in milliseconds
> ldap.connectTimeout=3000
> # Whether to use StartTLS (probably needed if not SSL connection)
> ldap.useStartTLS=false
> #
> # LDAP connection pool configuration
> #
> ldap.pool.minSize=3
> ldap.pool.maxSize=10
> ldap.pool.validateOnCheckout=false
> ldap.pool.validatePeriodically=true
> ldap.pool.blockWaitTime=3000
> ldap.pool.validatePeriod=300
> ldap.pool.prunePeriod=300
> ldap.pool.idleTime=600
> #
> # Authentication
> #
> # Base DN of users to be authenticated
> ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
> # Manager DN for authenticated searches
> ldap.authn.managerDn=admin_acco...@id.fuller.edu 
> 
> # Manager password for authenticated searches
> ldap.authn.managerPassword=admin_password
> # Search filter used for configurations that require searching for DNs
> ldap.authn.searchFilter=(sAMAccountName={user})
> # Domain Setting
> ldap.domain=fuller.edu 
> ldap.trustedCert=file:/etc/cas/id_app.pem
>
> and am attaching my current deployerConfigContext.xml file to this email.
>
> Thanks again,
>
> Mike
>
>
> On Tue, Jun 30, 2015 at 3:27 PM, Mike Seiler  > wrote:
>
> Thank you Mihai and John.
>
> I will try those things first thing in the morning and get back to
> you with all the additional logs and details.
>
> Mike
>
> On Tue, Jun 30, 2015 at 3:22 PM, John Ryan  > wrote:
>
> Mike,
>
> I think Daniel is on to something: we see no indication
> whatsoever in your log output that LDAP authentication is even
> being attempted.  In your log4j.xml please dial way back
> everything (most especially org.springframework) to WARN
> except//org.jasig and org.ldaptive (set both to TRACE).  After
> you attempt to hit a CAS-ified application, we should then see
> a rich set of detail about CAS placing a service in FlowScope,
> generating a login ticket, etc.
>
> If everything is OK up to that point, we'll see an "Attempting
> LDAP authentication" message from
> org.jasig.cas.authentication.LdapAuthenticationHandler,
> followed by rich detail from org.ldaptive components as they
> interact with AD.
>
> FYI we're using CAS 4.0 with AD and it is working fine.  The
> only differences that jump out to me from our configuration is
> that we don't use any of the ldap.authn properties at all, as
> we want to use the user's sAMAccountName.
>
> Also, one departure from the deployerConfigContext.xml at
> 
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
>  

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Thank you all for your suggestions and help.  I touch CAS maybe once a year
when changes are needed, so I'm not very savvy.

By setting the log values to TRACE I was able to determine that CAS was
never initiating the ldap search (as Daniel pointed out) and figure out
what was causing that.

The authentication *succeeded* after the following:
1) Using the 2nd option (LDAP Requiring Authenticated Search), and fixing
differences in the sample code and my cas.properties file (e.g.
ldap.managerDn vs ldap.authn.managerDn)
2) changing the the managerDN to the admin_acco...@id.fuller.edu -- in the
3.5.2 installation, I used the full CN=CASADMIN, etc...
3) setting useStartTLS=false
4) setting searchFilter to (sAMAccountName={user}) -- anything else seems
to fail

The response from the server (in catalina.out) contains all the attributes
I'm hoping to get (and then some), so it seems that the attribute mapping
is working as well.  I'll find out more when I modify the authorization
plugins for our external apps to pull the CAS attributes list.

*SSL*
It seems that disabling/enabling the sslConfig bean makes no difference in
my config; the certs are stored in the default keystore as well, so both
methods build and authenticate.

In the interest of helping fellow Google searchers down the road, I've
attached my LDAP properties section of the cas.properties file below:

#
# General properties
#
ldap.url=ldaps://id.fuller.edu
# LDAP connection timeout in milliseconds
ldap.connectTimeout=3000
# Whether to use StartTLS (probably needed if not SSL connection)
ldap.useStartTLS=false
#
# LDAP connection pool configuration
#
ldap.pool.minSize=3
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
ldap.pool.blockWaitTime=3000
ldap.pool.validatePeriod=300
ldap.pool.prunePeriod=300
ldap.pool.idleTime=600
#
# Authentication
#
# Base DN of users to be authenticated
ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
# Manager DN for authenticated searches
ldap.authn.managerDn=admin_acco...@id.fuller.edu
# Manager password for authenticated searches
ldap.authn.managerPassword=admin_password
# Search filter used for configurations that require searching for DNs
ldap.authn.searchFilter=(sAMAccountName={user})
# Domain Setting
ldap.domain=fuller.edu
ldap.trustedCert=file:/etc/cas/id_app.pem

and am attaching my current deployerConfigContext.xml file to this email.

Thanks again,

Mike


On Tue, Jun 30, 2015 at 3:27 PM, Mike Seiler 
wrote:

> Thank you Mihai and John.
>
> I will try those things first thing in the morning and get back to you
> with all the additional logs and details.
>
> Mike
>
> On Tue, Jun 30, 2015 at 3:22 PM, John Ryan  wrote:
>
>>  Mike,
>>
>> I think Daniel is on to something: we see no indication whatsoever in
>> your log output that LDAP authentication is even being attempted.  In your
>> log4j.xml please dial way back everything (most especially
>> org.springframework) to WARN except org.jasig and org.ldaptive (set both
>> to TRACE).  After you attempt to hit a CAS-ified application, we should
>> then see a rich set of detail about CAS placing a service in FlowScope,
>> generating a login ticket, etc.
>>
>> If everything is OK up to that point, we'll see an "Attempting LDAP
>> authentication" message from
>> org.jasig.cas.authentication.LdapAuthenticationHandler, followed by rich
>> detail from org.ldaptive components as they interact with AD.
>>
>> FYI we're using CAS 4.0 with AD and it is working fine.  The only
>> differences that jump out to me from our configuration is that we don't use
>> any of the ldap.authn properties at all, as we want to use the user's
>> sAMAccountName.
>>
>> Also, one departure from the deployerConfigContext.xml at
>> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
>> is that we do not use an sslConfig bean.  We use ldaps, the cert for our AD
>> server is in the JVM's keystore, and things seem to work just fine without
>> the sslConfig bean.
>>
>> But again, we see no indication an attempt at LDAP authentication is even
>> being attempted.  Updating log4j.xml with the suggested changes should at
>> least make that clear.
>>
>> On 6/29/2015 9:26 PM, Daniel Fisher wrote:
>>
>>  On Mon, Jun 29, 2015 at 1:28 PM, Mike Seiler 
>> wrote:
>>
>>> Any further suggestions on what might be causing the system to fail to
>>> authenticate users?
>>>
>>>  Bind with manager password works. Certificates validate.
>>> sAMAccountName is set as the search filter.
>>>
>>>  Any suggestions would be appreciated.
>>>
>>
>>  I didn't see the LDAP authentication component being exercised. Your
>> LDAP pools initialize correctly, but the authentication handler does not
>> appear to use t

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Thank you Mihai and John.

I will try those things first thing in the morning and get back to you with
all the additional logs and details.

Mike

On Tue, Jun 30, 2015 at 3:22 PM, John Ryan  wrote:

>  Mike,
>
> I think Daniel is on to something: we see no indication whatsoever in your
> log output that LDAP authentication is even being attempted.  In your
> log4j.xml please dial way back everything (most especially
> org.springframework) to WARN except org.jasig and org.ldaptive (set both
> to TRACE).  After you attempt to hit a CAS-ified application, we should
> then see a rich set of detail about CAS placing a service in FlowScope,
> generating a login ticket, etc.
>
> If everything is OK up to that point, we'll see an "Attempting LDAP
> authentication" message from
> org.jasig.cas.authentication.LdapAuthenticationHandler, followed by rich
> detail from org.ldaptive components as they interact with AD.
>
> FYI we're using CAS 4.0 with AD and it is working fine.  The only
> differences that jump out to me from our configuration is that we don't use
> any of the ldap.authn properties at all, as we want to use the user's
> sAMAccountName.
>
> Also, one departure from the deployerConfigContext.xml at
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
> is that we do not use an sslConfig bean.  We use ldaps, the cert for our AD
> server is in the JVM's keystore, and things seem to work just fine without
> the sslConfig bean.
>
> But again, we see no indication an attempt at LDAP authentication is even
> being attempted.  Updating log4j.xml with the suggested changes should at
> least make that clear.
>
> On 6/29/2015 9:26 PM, Daniel Fisher wrote:
>
>  On Mon, Jun 29, 2015 at 1:28 PM, Mike Seiler 
> wrote:
>
>> Any further suggestions on what might be causing the system to fail to
>> authenticate users?
>>
>>  Bind with manager password works. Certificates validate. sAMAccountName
>> is set as the search filter.
>>
>>  Any suggestions would be appreciated.
>>
>
>  I didn't see the LDAP authentication component being exercised. Your
> LDAP pools initialize correctly, but the authentication handler does not
> appear to use them. I don't know enough about the v4 config to say what's
> wrong, but I would look for something fundamental in the authentication
> wiring, not in the LDAP config.
>
>  --Daniel Fisher
>
>   --
> You are currently subscribed to cas-user@lists.jasig.org as: jr...@redzone.co
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
> --
>  John Ryan  / Senior Software Engineer /  RedZone Software
> jr...@redzone.co  /  www.redzone.co
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: 
> michaelsei...@fuller.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>
> This transmission contains confidential information intended solely for
> the party identified above. If you receive this message in error, you must
> not use it or convey it to others. Please destroy it immediately and
> contact the sender at (303) 386-3955 or by return e-mail to the sender.




-- 
*Michael Seiler*
--
Systems Integration Engineer
Fuller Theological Seminary
Phone: (970) 306-6105
michaelsei...@fuller.edu

*Fuller Summer Hours:* Please note that all Fuller offices will be closed
on Fridays from 7/3-8/28
*Mike's Vacation Notice:* From 7/3-8/28 I will also be taking Mondays off,
and will be out of the office for vacation 7/31 - 8/31

*Please NOTE:*
I respond to email at 8 AM, 1PM, and at 4:30PM.  If you need more immediate
help, please contact TSS (626.584.5675) and they can route the issue to the
appropriate person.  If this is a business process life or death emergency,
you may call me at the above number.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Help with CAS 4.0 & AD

[John Ryan]

Mike,

I think Daniel is on to something: we see no indication whatsoever in 
your log output that LDAP authentication is even being attempted.  In 
your log4j.xml please dial way back everything (most especially 
org.springframework) to WARN except//org.jasig and org.ldaptive (set 
both to TRACE).  After you attempt to hit a CAS-ified application, we 
should then see a rich set of detail about CAS placing a service in 
FlowScope, generating a login ticket, etc.

If everything is OK up to that point, we'll see an "Attempting LDAP 
authentication" message from 
org.jasig.cas.authentication.LdapAuthenticationHandler, followed by rich 
detail from org.ldaptive components as they interact with AD.

FYI we're using CAS 4.0 with AD and it is working fine.  The only 
differences that jump out to me from our configuration is that we don't 
use any of the ldap.authn properties at all, as we want to use the 
user's sAMAccountName.

Also, one departure from the deployerConfigContext.xml at 
http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
 
is that we do not use an sslConfig bean.  We use ldaps, the cert for our 
AD server is in the JVM's keystore, and things seem to work just fine 
without the sslConfig bean.

But again, we see no indication an attempt at LDAP authentication is 
even being attempted.  Updating log4j.xml with the suggested changes 
should at least make that clear.

On 6/29/2015 9:26 PM, Daniel Fisher wrote:
> On Mon, Jun 29, 2015 at 1:28 PM, Mike Seiler  > wrote:
>
> Any further suggestions on what might be causing the system to
> fail to authenticate users?
>
> Bind with manager password works. Certificates validate.
> sAMAccountName is set as the search filter.
>
> Any suggestions would be appreciated.
>
>
> I didn't see the LDAP authentication component being exercised. Your 
> LDAP pools initialize correctly, but the authentication handler does 
> not appear to use them. I don't know enough about the v4 config to say 
> what's wrong, but I would look for something fundamental in the 
> authentication wiring, not in the LDAP config.
>
> --Daniel Fisher
>
> -- 
> You are currently subscribed to cas-user@lists.jasig.org as: jr...@redzone.co
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
John Ryan  / Senior Software Engineer / RedZone Software
jr...@redzone.co   / www.redzone.co 


-- 
This transmission contains confidential information intended solely for the 
party identified above. If you receive this message in error, you must not 
use it or convey it to others. Please destroy it immediately and contact 
the sender at (303) 386-3955 or by return e-mail to the sender.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] Help with CAS 4.0 & AD

[Mihai Petcu]

Hello Mike.

We are using CAS 4.0.2 with AD.

In cas.properties, we are using [sAMAccountName]@[ldap Url] for 
ldap.authn.managerDN and is working.

In your case it will be

ldap.authn.managerDN=admin_acco...@id.fuller.edu



But we are using second variant, 
ldap_requiring_authenticated_search<http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#ldap_requiring_authenticated_search>;
 I understood you are using the first variant, 
active_directory_authentication<http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication>,
 so it should not matter what you have in cas.properties for managerDN because 
it’s not using it, from what I can tell.



Can you comment those lines in cas.properties to test what’s the result ?


From: Mike Seiler [mailto:michaelsei...@fuller.edu]
Sent: Wednesday, July 01, 2015 01:11
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Thanks Mearl,

I'll take a look at implementing that method then instead of the first on the 
list.

In my command line searches, I've made sure to pull the userPrincipalName and 
they do indeed come back as 
samaccountn...@fuller.edu<mailto:samaccountn...@fuller.edu>.

Mike

On Tue, Jun 30, 2015 at 3:06 PM, Danner, Mearl 
mailto:jmdan...@samford.edu>> wrote:
If you need the memberOf attribute you’ll need to use the authenticated bind 
plus search method.

The method using only samaccountname does not return attributes. It only gives 
a yes/no on the authentication. The example shows an attribute map, but it will 
not do anything.

In your case about the authentication of your userid you might need to look at 
your AD record to see if the userprinciplename is really your 
samaccountname@domain. It is that by default, but provisioning or an admin can 
change it.

From: Mike Seiler 
[mailto:michaelsei...@fuller.edu<mailto:michaelsei...@fuller.edu>]
Sent: Tuesday, June 30, 2015 4:34 PM
To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>

Subject: Re: [cas-user] Help with CAS 4.0 & AD

Carl,

All of our users are in fact in one distinct OU in the AD (ou=fuller), and we 
then manage web access by the "memberOf" attribute in each of our individual 
external apps (e.g. StudentMembers, AlumMembers, EmployeeMembers, etc).  Right 
now, these apps only get the username from CAS -- and not the full attributes 
list -- and then have to perform a separate query to the AD to get the 
membership attribute for the authorization portion of logging in to the 
particular app.

I was hoping to bypass all that with v4.0's attribute mapping (among other 
added benefits), which is why I'm building out this new server.  It would give 
us a smaller maintenance footprint (fewer firewall mods, fewer certificate 
installs, fewer network calls, etc.); I know that the attribute mapping is 
possible in 3.5 (with some additional modifications), so I may just revert back 
to tinkering with a test instance of the current set up instead.

Thanks,

Mike

On Tue, Jun 30, 2015 at 2:03 PM, Waldbieser, Carl 
mailto:waldb...@lafayette.edu>> wrote:
Mike,

I think the key part is "without performing a search" in the quote I pulled 
from the A/D section.
I am not sure how that is possible in traditional LDAP unless all the accounts 
are in a single ou that has been configured beforehand.
Our LDAP DIT is "context-crazy" aka "bushy", with accounts for different 
departments in different ous.

I am not sure how that would work using LDAP.  Could just be something unclear 
in the text, though.

Thanks,
Carl

- Original Message -
From: "Mike Seiler" mailto:michaelsei...@fuller.edu>>
To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>
Sent: Tuesday, June 30, 2015 4:59:00 PM
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Carl,

Our current CAS server (3.5.2) simply binds as the manager and then
authenticates the user from the AD with a search.  To me, that first
paragraph & sample code seems to suggest that it does the same thing -
using only the manager credentials to authenticate the user.

Thanks,

Mike

On Tue, Jun 30, 2015 at 1:17 PM, Waldbieser, Carl 
mailto:waldb...@lafayette.edu>>
wrote:

> Mike,
>
> I did notice this while going over the instructions:
>
>   "The following configuration authenticates users by sAMAccountName
> without performing a search, which requires manager/administrator
> credentials in most cases".
>
>   Is that something special you can do in A/D since sAMAccountName is
> guarunteed to be unique in the domain?  With typical LDAP authN, you need
> to do a search to get the full DN and then BIND as that DN.
>
> Still poking around ...
>
> Thanks,
> Carl
>
> ----- Original Message -----
> From: "Mike Seiler" 
&

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Thanks Mearl,

I'll take a look at implementing that method then instead of the first on
the list.

In my command line searches, I've made sure to pull the userPrincipalName
and they do indeed come back as samaccountn...@fuller.edu.

Mike

On Tue, Jun 30, 2015 at 3:06 PM, Danner, Mearl  wrote:

>  If you need the memberOf attribute you’ll need to use the authenticated
> bind plus search method.
>
>
>
> The method using only samaccountname does not return attributes. It only
> gives a yes/no on the authentication. The example shows an attribute map,
> but it will not do anything.
>
>
>
> In your case about the authentication of your userid you might need to
> look at your AD record to see if the userprinciplename is really your
> samaccountname@domain. It is that by default, but provisioning or an
> admin can change it.
>
>
>
> *From:* Mike Seiler [mailto:michaelsei...@fuller.edu]
> *Sent:* Tuesday, June 30, 2015 4:34 PM
> *To:* cas-user@lists.jasig.org
>
> *Subject:* Re: [cas-user] Help with CAS 4.0 & AD
>
>
>
> Carl,
>
>
>
> All of our users are in fact in one distinct OU in the AD (ou=fuller), and
> we then manage web access by the "memberOf" attribute in each of our
> individual external apps (e.g. StudentMembers, AlumMembers,
> EmployeeMembers, etc).  Right now, these apps only get the username from
> CAS -- and not the full attributes list -- and then have to perform a
> separate query to the AD to get the membership attribute for the
> authorization portion of logging in to the particular app.
>
>
>
> I was hoping to bypass all that with v4.0's attribute mapping (among other
> added benefits), which is why I'm building out this new server.  It would
> give us a smaller maintenance footprint (fewer firewall mods, fewer
> certificate installs, fewer network calls, etc.); I know that the attribute
> mapping is possible in 3.5 (with some additional modifications), so I may
> just revert back to tinkering with a test instance of the current set up
> instead.
>
>
>
> Thanks,
>
>
>
> Mike
>
>
>
> On Tue, Jun 30, 2015 at 2:03 PM, Waldbieser, Carl 
> wrote:
>
> Mike,
>
> I think the key part is "without performing a search" in the quote I
> pulled from the A/D section.
> I am not sure how that is possible in traditional LDAP unless all the
> accounts are in a single ou that has been configured beforehand.
> Our LDAP DIT is "context-crazy" aka "bushy", with accounts for different
> departments in different ous.
>
> I am not sure how that would work using LDAP.  Could just be something
> unclear in the text, though.
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> To: cas-user@lists.jasig.org
>
> Sent: Tuesday, June 30, 2015 4:59:00 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> Carl,
>
> Our current CAS server (3.5.2) simply binds as the manager and then
> authenticates the user from the AD with a search.  To me, that first
> paragraph & sample code seems to suggest that it does the same thing -
> using only the manager credentials to authenticate the user.
>
> Thanks,
>
> Mike
>
> On Tue, Jun 30, 2015 at 1:17 PM, Waldbieser, Carl 
> wrote:
>
> > Mike,
> >
> > I did notice this while going over the instructions:
> >
> >   "The following configuration authenticates users by sAMAccountName
> > without performing a search, which requires manager/administrator
> > credentials in most cases".
> >
> >   Is that something special you can do in A/D since sAMAccountName is
> > guarunteed to be unique in the domain?  With typical LDAP authN, you need
> > to do a search to get the full DN and then BIND as that DN.
> >
> > Still poking around ...
> >
> > Thanks,
> > Carl
> >
> > - Original Message -
> > From: "Mike Seiler" 
> > To: cas-user@lists.jasig.org
> > Sent: Tuesday, June 30, 2015 3:39:02 PM
> > Subject: Re: [cas-user] Help with CAS 4.0 & AD
> >
> > Here's my cas.properties info:
> > #
> > # General properties
> > #
> > ldap.url=ldaps://id.fuller.edu
> > ldap.connectTimeout=3000
> > ldap.useStartTLS=false
> >
> > #
> > # LDAP connection pool configuration
> > #
> > ldap.pool.minSize=3
> > ldap.pool.maxSize=10
> > ldap.pool.validateOnCheckout=false
> > ldap.pool.validatePeriodically=true
> &g

RE: [cas-user] Help with CAS 4.0 & AD

[Danner, Mearl]

If you need the memberOf attribute you’ll need to use the authenticated bind 
plus search method.

The method using only samaccountname does not return attributes. It only gives 
a yes/no on the authentication. The example shows an attribute map, but it will 
not do anything.

In your case about the authentication of your userid you might need to look at 
your AD record to see if the userprinciplename is really your 
samaccountname@domain. It is that by default, but provisioning or an admin can 
change it.

From: Mike Seiler [mailto:michaelsei...@fuller.edu]
Sent: Tuesday, June 30, 2015 4:34 PM
To: cas-user@lists.jasig.org
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Carl,

All of our users are in fact in one distinct OU in the AD (ou=fuller), and we 
then manage web access by the "memberOf" attribute in each of our individual 
external apps (e.g. StudentMembers, AlumMembers, EmployeeMembers, etc).  Right 
now, these apps only get the username from CAS -- and not the full attributes 
list -- and then have to perform a separate query to the AD to get the 
membership attribute for the authorization portion of logging in to the 
particular app.

I was hoping to bypass all that with v4.0's attribute mapping (among other 
added benefits), which is why I'm building out this new server.  It would give 
us a smaller maintenance footprint (fewer firewall mods, fewer certificate 
installs, fewer network calls, etc.); I know that the attribute mapping is 
possible in 3.5 (with some additional modifications), so I may just revert back 
to tinkering with a test instance of the current set up instead.

Thanks,

Mike

On Tue, Jun 30, 2015 at 2:03 PM, Waldbieser, Carl 
mailto:waldb...@lafayette.edu>> wrote:
Mike,

I think the key part is "without performing a search" in the quote I pulled 
from the A/D section.
I am not sure how that is possible in traditional LDAP unless all the accounts 
are in a single ou that has been configured beforehand.
Our LDAP DIT is "context-crazy" aka "bushy", with accounts for different 
departments in different ous.

I am not sure how that would work using LDAP.  Could just be something unclear 
in the text, though.

Thanks,
Carl

- Original Message -
From: "Mike Seiler" mailto:michaelsei...@fuller.edu>>
To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>
Sent: Tuesday, June 30, 2015 4:59:00 PM
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Carl,

Our current CAS server (3.5.2) simply binds as the manager and then
authenticates the user from the AD with a search.  To me, that first
paragraph & sample code seems to suggest that it does the same thing -
using only the manager credentials to authenticate the user.

Thanks,

Mike

On Tue, Jun 30, 2015 at 1:17 PM, Waldbieser, Carl 
mailto:waldb...@lafayette.edu>>
wrote:

> Mike,
>
> I did notice this while going over the instructions:
>
>   "The following configuration authenticates users by sAMAccountName
> without performing a search, which requires manager/administrator
> credentials in most cases".
>
>   Is that something special you can do in A/D since sAMAccountName is
> guarunteed to be unique in the domain?  With typical LDAP authN, you need
> to do a search to get the full DN and then BIND as that DN.
>
> Still poking around ...
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> mailto:michaelsei...@fuller.edu>>
> To: cas-user@lists.jasig.org<mailto:cas-user@lists.jasig.org>
> Sent: Tuesday, June 30, 2015 3:39:02 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> Here's my cas.properties info:
> #
> # General properties
> #
> ldap.url=ldaps://id.fuller.edu<http://id.fuller.edu>
> ldap.connectTimeout=3000
> ldap.useStartTLS=false
>
> #
> # LDAP connection pool configuration
> #
> ldap.pool.minSize=3
> ldap.pool.maxSize=10
> ldap.pool.validateOnCheckout=false
> ldap.pool.validatePeriodically=true
> ldap.pool.blockWaitTime=3000
> ldap.pool.validatePeriod=300
> ldap.pool.prunePeriod=300
> ldap.pool.idleTime=600
>
> #
> # Authentication
> #
> # Base DN of users to be authenticated
> ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
> # the CN=Users here because the CASADMIN is outside the "ou" we put our
> normal users into.
> ldap.authn.managerDN=CN=CASADMIN,CN=Users,DC=id,DC=fuller,DC=edu
> ldap.authn.managerPassword=
> ldap.domain=fuller.edu<http://fuller.edu>
> ldap.trustedCert=file:/etc/cas/id_app.pem
> # [The cut and paste

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Carl,

All of our users are in fact in one distinct OU in the AD (ou=fuller), and
we then manage web access by the "memberOf" attribute in each of our
individual external apps (e.g. StudentMembers, AlumMembers,
EmployeeMembers, etc).  Right now, these apps only get the username from
CAS -- and not the full attributes list -- and then have to perform a
separate query to the AD to get the membership attribute for the
authorization portion of logging in to the particular app.

I was hoping to bypass all that with v4.0's attribute mapping (among other
added benefits), which is why I'm building out this new server.  It would
give us a smaller maintenance footprint (fewer firewall mods, fewer
certificate installs, fewer network calls, etc.); I know that the attribute
mapping is possible in 3.5 (with some additional modifications), so I may
just revert back to tinkering with a test instance of the current set up
instead.

Thanks,

Mike

On Tue, Jun 30, 2015 at 2:03 PM, Waldbieser, Carl 
wrote:

> Mike,
>
> I think the key part is "without performing a search" in the quote I
> pulled from the A/D section.
> I am not sure how that is possible in traditional LDAP unless all the
> accounts are in a single ou that has been configured beforehand.
> Our LDAP DIT is "context-crazy" aka "bushy", with accounts for different
> departments in different ous.
>
> I am not sure how that would work using LDAP.  Could just be something
> unclear in the text, though.
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> To: cas-user@lists.jasig.org
> Sent: Tuesday, June 30, 2015 4:59:00 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> Carl,
>
> Our current CAS server (3.5.2) simply binds as the manager and then
> authenticates the user from the AD with a search.  To me, that first
> paragraph & sample code seems to suggest that it does the same thing -
> using only the manager credentials to authenticate the user.
>
> Thanks,
>
> Mike
>
> On Tue, Jun 30, 2015 at 1:17 PM, Waldbieser, Carl 
> wrote:
>
> > Mike,
> >
> > I did notice this while going over the instructions:
> >
> >   "The following configuration authenticates users by sAMAccountName
> > without performing a search, which requires manager/administrator
> > credentials in most cases".
> >
> >   Is that something special you can do in A/D since sAMAccountName is
> > guarunteed to be unique in the domain?  With typical LDAP authN, you need
> > to do a search to get the full DN and then BIND as that DN.
> >
> > Still poking around ...
> >
> > Thanks,
> > Carl
> >
> > - Original Message -
> > From: "Mike Seiler" 
> > To: cas-user@lists.jasig.org
> > Sent: Tuesday, June 30, 2015 3:39:02 PM
> > Subject: Re: [cas-user] Help with CAS 4.0 & AD
> >
> > Here's my cas.properties info:
> > #
> > # General properties
> > #
> > ldap.url=ldaps://id.fuller.edu
> > ldap.connectTimeout=3000
> > ldap.useStartTLS=false
> >
> > #
> > # LDAP connection pool configuration
> > #
> > ldap.pool.minSize=3
> > ldap.pool.maxSize=10
> > ldap.pool.validateOnCheckout=false
> > ldap.pool.validatePeriodically=true
> > ldap.pool.blockWaitTime=3000
> > ldap.pool.validatePeriod=300
> > ldap.pool.prunePeriod=300
> > ldap.pool.idleTime=600
> >
> > #
> > # Authentication
> > #
> > # Base DN of users to be authenticated
> > ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
> > # the CN=Users here because the CASADMIN is outside the "ou" we put our
> > normal users into.
> > ldap.authn.managerDN=CN=CASADMIN,CN=Users,DC=id,DC=fuller,DC=edu
> > ldap.authn.managerPassword=
> > ldap.domain=fuller.edu
> > ldap.trustedCert=file:/etc/cas/id_app.pem
> > # [The cut and paste deployer config doesn't actually use the below, but
> I
> > modified them anyway]
> > ldap.authn.searchFilter=(sAMAccountName=%s)
> > ldap.authn.format=%s...@fuller.edu
> >
> > Thanks for taking a looking at this.
> >
> > On Tue, Jun 30, 2015 at 12:06 PM, Waldbieser, Carl <
> waldb...@lafayette.edu
> > >
> > wrote:
> >
> > > Mike,
> > >
> > > Could you post the non-sensitive parts of your LDAP configuration?
> > > We are using CA

Re: [cas-user] Help with CAS 4.0 & AD

[Waldbieser, Carl]

Mike,

I think the key part is "without performing a search" in the quote I pulled 
from the A/D section.
I am not sure how that is possible in traditional LDAP unless all the accounts 
are in a single ou that has been configured beforehand.
Our LDAP DIT is "context-crazy" aka "bushy", with accounts for different 
departments in different ous.

I am not sure how that would work using LDAP.  Could just be something unclear 
in the text, though.

Thanks,
Carl

- Original Message -
From: "Mike Seiler" 
To: cas-user@lists.jasig.org
Sent: Tuesday, June 30, 2015 4:59:00 PM
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Carl,

Our current CAS server (3.5.2) simply binds as the manager and then
authenticates the user from the AD with a search.  To me, that first
paragraph & sample code seems to suggest that it does the same thing -
using only the manager credentials to authenticate the user.

Thanks,

Mike

On Tue, Jun 30, 2015 at 1:17 PM, Waldbieser, Carl 
wrote:

> Mike,
>
> I did notice this while going over the instructions:
>
>   "The following configuration authenticates users by sAMAccountName
> without performing a search, which requires manager/administrator
> credentials in most cases".
>
>   Is that something special you can do in A/D since sAMAccountName is
> guarunteed to be unique in the domain?  With typical LDAP authN, you need
> to do a search to get the full DN and then BIND as that DN.
>
> Still poking around ...
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> To: cas-user@lists.jasig.org
> Sent: Tuesday, June 30, 2015 3:39:02 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> Here's my cas.properties info:
> #
> # General properties
> #
> ldap.url=ldaps://id.fuller.edu
> ldap.connectTimeout=3000
> ldap.useStartTLS=false
>
> #
> # LDAP connection pool configuration
> #
> ldap.pool.minSize=3
> ldap.pool.maxSize=10
> ldap.pool.validateOnCheckout=false
> ldap.pool.validatePeriodically=true
> ldap.pool.blockWaitTime=3000
> ldap.pool.validatePeriod=300
> ldap.pool.prunePeriod=300
> ldap.pool.idleTime=600
>
> #
> # Authentication
> #
> # Base DN of users to be authenticated
> ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
> # the CN=Users here because the CASADMIN is outside the "ou" we put our
> normal users into.
> ldap.authn.managerDN=CN=CASADMIN,CN=Users,DC=id,DC=fuller,DC=edu
> ldap.authn.managerPassword=
> ldap.domain=fuller.edu
> ldap.trustedCert=file:/etc/cas/id_app.pem
> # [The cut and paste deployer config doesn't actually use the below, but I
> modified them anyway]
> ldap.authn.searchFilter=(sAMAccountName=%s)
> ldap.authn.format=%s...@fuller.edu
>
> Thanks for taking a looking at this.
>
> On Tue, Jun 30, 2015 at 12:06 PM, Waldbieser, Carl  >
> wrote:
>
> > Mike,
> >
> > Could you post the non-sensitive parts of your LDAP configuration?
> > We are using CAS 3.x and usin OpenLDAP so it is not necessarily a good
> > match, but our settings look like:
> >
> > # == LDAP Authentication settings ==
> > ldap.authentication.filter=uid=%u
> > ldap.authentication.server.urls=ldaps://ldap.lafayette.edu
> > ldap.authentication.basedn=O=lafayette
> > ldap.authentication.manager.userdn=cn=casbrowser,o=lafayette
> > ldap.authentication.manager.password=REDACTED
> > ldap.authentication.ignorePartialResultException=true
> > ldap.authentication.scope=2
> > ldap.authentication.jndi.connect.timeout=3000
> > ldap.authentication.jndi.read.timeout=3000
> > ldap.authentication.jndi.security.level=simple
> >
> >
> > Thanks,
> > Carl
> >
> > - Original Message -
> > From: "Mike Seiler" 
> > To: cas-user@lists.jasig.org
> > Sent: Tuesday, June 30, 2015 2:44:32 PM
> > Subject: Re: [cas-user] Help with CAS 4.0 & AD
> >
> > The AD is set to allow global search by all authenticated users; any
> thing
> > else (resetting password, etc) requires the administrator credentials -
> but
> > we don't use the Password Manager in CAS - we do that externally via
> other
> > apps.  All we need is to determine that a user's account authenticates
> and
> > pass the attributes on to other applications.
> >
> > I'm using the deployerConfigContext defined here:
> >
> >
> http://jasig.github.io/cas/4

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Carl,

Our current CAS server (3.5.2) simply binds as the manager and then
authenticates the user from the AD with a search.  To me, that first
paragraph & sample code seems to suggest that it does the same thing -
using only the manager credentials to authenticate the user.

Thanks,

Mike

On Tue, Jun 30, 2015 at 1:17 PM, Waldbieser, Carl 
wrote:

> Mike,
>
> I did notice this while going over the instructions:
>
>   "The following configuration authenticates users by sAMAccountName
> without performing a search, which requires manager/administrator
> credentials in most cases".
>
>   Is that something special you can do in A/D since sAMAccountName is
> guarunteed to be unique in the domain?  With typical LDAP authN, you need
> to do a search to get the full DN and then BIND as that DN.
>
> Still poking around ...
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> To: cas-user@lists.jasig.org
> Sent: Tuesday, June 30, 2015 3:39:02 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> Here's my cas.properties info:
> #
> # General properties
> #
> ldap.url=ldaps://id.fuller.edu
> ldap.connectTimeout=3000
> ldap.useStartTLS=false
>
> #
> # LDAP connection pool configuration
> #
> ldap.pool.minSize=3
> ldap.pool.maxSize=10
> ldap.pool.validateOnCheckout=false
> ldap.pool.validatePeriodically=true
> ldap.pool.blockWaitTime=3000
> ldap.pool.validatePeriod=300
> ldap.pool.prunePeriod=300
> ldap.pool.idleTime=600
>
> #
> # Authentication
> #
> # Base DN of users to be authenticated
> ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
> # the CN=Users here because the CASADMIN is outside the "ou" we put our
> normal users into.
> ldap.authn.managerDN=CN=CASADMIN,CN=Users,DC=id,DC=fuller,DC=edu
> ldap.authn.managerPassword=
> ldap.domain=fuller.edu
> ldap.trustedCert=file:/etc/cas/id_app.pem
> # [The cut and paste deployer config doesn't actually use the below, but I
> modified them anyway]
> ldap.authn.searchFilter=(sAMAccountName=%s)
> ldap.authn.format=%s...@fuller.edu
>
> Thanks for taking a looking at this.
>
> On Tue, Jun 30, 2015 at 12:06 PM, Waldbieser, Carl  >
> wrote:
>
> > Mike,
> >
> > Could you post the non-sensitive parts of your LDAP configuration?
> > We are using CAS 3.x and usin OpenLDAP so it is not necessarily a good
> > match, but our settings look like:
> >
> > # == LDAP Authentication settings ==
> > ldap.authentication.filter=uid=%u
> > ldap.authentication.server.urls=ldaps://ldap.lafayette.edu
> > ldap.authentication.basedn=O=lafayette
> > ldap.authentication.manager.userdn=cn=casbrowser,o=lafayette
> > ldap.authentication.manager.password=REDACTED
> > ldap.authentication.ignorePartialResultException=true
> > ldap.authentication.scope=2
> > ldap.authentication.jndi.connect.timeout=3000
> > ldap.authentication.jndi.read.timeout=3000
> > ldap.authentication.jndi.security.level=simple
> >
> >
> > Thanks,
> > Carl
> >
> > - Original Message -
> > From: "Mike Seiler" 
> > To: cas-user@lists.jasig.org
> > Sent: Tuesday, June 30, 2015 2:44:32 PM
> > Subject: Re: [cas-user] Help with CAS 4.0 & AD
> >
> > The AD is set to allow global search by all authenticated users; any
> thing
> > else (resetting password, etc) requires the administrator credentials -
> but
> > we don't use the Password Manager in CAS - we do that externally via
> other
> > apps.  All we need is to determine that a user's account authenticates
> and
> > pass the attributes on to other applications.
> >
> > I'm using the deployerConfigContext defined here:
> >
> >
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
> > (The first code sample, which says "The following configuration
> > authenticates users by sAMAccountName without performing a search, which
> > requires manager/administrator credentials in most cases. It is therefore
> > the most performant and secure solution for the typical Active Directory
> > deployment.")
> >
> > *From the command line:* I am able to do an ldapsearch using my own
> > credentials (and looking up another user), and, of course, I am also able
> > to do a search for another user using the Admin credential

Re: [cas-user] Help with CAS 4.0 & AD

[Waldbieser, Carl]

Mike,

I did notice this while going over the instructions:

  "The following configuration authenticates users by sAMAccountName without 
performing a search, which requires manager/administrator credentials in most 
cases".

  Is that something special you can do in A/D since sAMAccountName is 
guarunteed to be unique in the domain?  With typical LDAP authN, you need to do 
a search to get the full DN and then BIND as that DN.

Still poking around ...

Thanks,
Carl

- Original Message -
From: "Mike Seiler" 
To: cas-user@lists.jasig.org
Sent: Tuesday, June 30, 2015 3:39:02 PM
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Here's my cas.properties info:
#
# General properties
#
ldap.url=ldaps://id.fuller.edu
ldap.connectTimeout=3000
ldap.useStartTLS=false

#
# LDAP connection pool configuration
#
ldap.pool.minSize=3
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
ldap.pool.blockWaitTime=3000
ldap.pool.validatePeriod=300
ldap.pool.prunePeriod=300
ldap.pool.idleTime=600

#
# Authentication
#
# Base DN of users to be authenticated
ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
# the CN=Users here because the CASADMIN is outside the "ou" we put our
normal users into.
ldap.authn.managerDN=CN=CASADMIN,CN=Users,DC=id,DC=fuller,DC=edu
ldap.authn.managerPassword=
ldap.domain=fuller.edu
ldap.trustedCert=file:/etc/cas/id_app.pem
# [The cut and paste deployer config doesn't actually use the below, but I
modified them anyway]
ldap.authn.searchFilter=(sAMAccountName=%s)
ldap.authn.format=%s...@fuller.edu

Thanks for taking a looking at this.

On Tue, Jun 30, 2015 at 12:06 PM, Waldbieser, Carl 
wrote:

> Mike,
>
> Could you post the non-sensitive parts of your LDAP configuration?
> We are using CAS 3.x and usin OpenLDAP so it is not necessarily a good
> match, but our settings look like:
>
> # == LDAP Authentication settings ==
> ldap.authentication.filter=uid=%u
> ldap.authentication.server.urls=ldaps://ldap.lafayette.edu
> ldap.authentication.basedn=O=lafayette
> ldap.authentication.manager.userdn=cn=casbrowser,o=lafayette
> ldap.authentication.manager.password=REDACTED
> ldap.authentication.ignorePartialResultException=true
> ldap.authentication.scope=2
> ldap.authentication.jndi.connect.timeout=3000
> ldap.authentication.jndi.read.timeout=3000
> ldap.authentication.jndi.security.level=simple
>
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> To: cas-user@lists.jasig.org
> Sent: Tuesday, June 30, 2015 2:44:32 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> The AD is set to allow global search by all authenticated users; any thing
> else (resetting password, etc) requires the administrator credentials - but
> we don't use the Password Manager in CAS - we do that externally via other
> apps.  All we need is to determine that a user's account authenticates and
> pass the attributes on to other applications.
>
> I'm using the deployerConfigContext defined here:
>
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
> (The first code sample, which says "The following configuration
> authenticates users by sAMAccountName without performing a search, which
> requires manager/administrator credentials in most cases. It is therefore
> the most performant and secure solution for the typical Active Directory
> deployment.")
>
> *From the command line:* I am able to do an ldapsearch using my own
> credentials (and looking up another user), and, of course, I am also able
> to do a search for another user using the Admin credentials:
>
> ldapsearch -x -H ldaps://id.fuller.edu  -b
> "ou=fuller,dc=id,dc=fuller,dc=edu" -D "admin_acco...@id.fuller.edu" -w
> "admin_password" "(sAMAccountName=michaelseiler)" cn sn displayName
> sAMAccountName pwdLastSet lastLogon mail memberof
>
> With either the admin credentials or my own, I get all requested data back
> from the server, but with CAS the validation of my own personal account
> credentials fails, and all I can seem to get from the error logs is that my
> own personal credentials are invalid -- even though I can use them from the
> command line and retrieve data for any user.
>
> It seems that this is a configuration error in CAS, but the error logs are
> insufficient to help debug this.
>
> Setting up a proxy to track down issues is beyond my knowledge.  If there
> is other documentation on setti

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Here's my cas.properties info:
#
# General properties
#
ldap.url=ldaps://id.fuller.edu
ldap.connectTimeout=3000
ldap.useStartTLS=false

#
# LDAP connection pool configuration
#
ldap.pool.minSize=3
ldap.pool.maxSize=10
ldap.pool.validateOnCheckout=false
ldap.pool.validatePeriodically=true
ldap.pool.blockWaitTime=3000
ldap.pool.validatePeriod=300
ldap.pool.prunePeriod=300
ldap.pool.idleTime=600

#
# Authentication
#
# Base DN of users to be authenticated
ldap.baseDn=ou=fuller,DC=id,DC=fuller,DC=edu
# the CN=Users here because the CASADMIN is outside the "ou" we put our
normal users into.
ldap.authn.managerDN=CN=CASADMIN,CN=Users,DC=id,DC=fuller,DC=edu
ldap.authn.managerPassword=
ldap.domain=fuller.edu
ldap.trustedCert=file:/etc/cas/id_app.pem
# [The cut and paste deployer config doesn't actually use the below, but I
modified them anyway]
ldap.authn.searchFilter=(sAMAccountName=%s)
ldap.authn.format=%s...@fuller.edu

Thanks for taking a looking at this.

On Tue, Jun 30, 2015 at 12:06 PM, Waldbieser, Carl 
wrote:

> Mike,
>
> Could you post the non-sensitive parts of your LDAP configuration?
> We are using CAS 3.x and usin OpenLDAP so it is not necessarily a good
> match, but our settings look like:
>
> # == LDAP Authentication settings ==
> ldap.authentication.filter=uid=%u
> ldap.authentication.server.urls=ldaps://ldap.lafayette.edu
> ldap.authentication.basedn=O=lafayette
> ldap.authentication.manager.userdn=cn=casbrowser,o=lafayette
> ldap.authentication.manager.password=REDACTED
> ldap.authentication.ignorePartialResultException=true
> ldap.authentication.scope=2
> ldap.authentication.jndi.connect.timeout=3000
> ldap.authentication.jndi.read.timeout=3000
> ldap.authentication.jndi.security.level=simple
>
>
> Thanks,
> Carl
>
> - Original Message -
> From: "Mike Seiler" 
> To: cas-user@lists.jasig.org
> Sent: Tuesday, June 30, 2015 2:44:32 PM
> Subject: Re: [cas-user] Help with CAS 4.0 & AD
>
> The AD is set to allow global search by all authenticated users; any thing
> else (resetting password, etc) requires the administrator credentials - but
> we don't use the Password Manager in CAS - we do that externally via other
> apps.  All we need is to determine that a user's account authenticates and
> pass the attributes on to other applications.
>
> I'm using the deployerConfigContext defined here:
>
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
> (The first code sample, which says "The following configuration
> authenticates users by sAMAccountName without performing a search, which
> requires manager/administrator credentials in most cases. It is therefore
> the most performant and secure solution for the typical Active Directory
> deployment.")
>
> *From the command line:* I am able to do an ldapsearch using my own
> credentials (and looking up another user), and, of course, I am also able
> to do a search for another user using the Admin credentials:
>
> ldapsearch -x -H ldaps://id.fuller.edu  -b
> "ou=fuller,dc=id,dc=fuller,dc=edu" -D "admin_acco...@id.fuller.edu" -w
> "admin_password" "(sAMAccountName=michaelseiler)" cn sn displayName
> sAMAccountName pwdLastSet lastLogon mail memberof
>
> With either the admin credentials or my own, I get all requested data back
> from the server, but with CAS the validation of my own personal account
> credentials fails, and all I can seem to get from the error logs is that my
> own personal credentials are invalid -- even though I can use them from the
> command line and retrieve data for any user.
>
> It seems that this is a configuration error in CAS, but the error logs are
> insufficient to help debug this.
>
> Setting up a proxy to track down issues is beyond my knowledge.  If there
> is other documentation on setting up CAS 4.0 with LDAP that doesn't use the
> Maven overlay method or the cut-and-paste code from the above URL, I'd be
> happy to try that out at this point.
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> waldb...@lafayette.edu
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as:
> michaelsei...@fuller.edu
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>



-- 
*Michael Seiler*

Re: [cas-user] Help with CAS 4.0 & AD

[Waldbieser, Carl]

Mike,

Could you post the non-sensitive parts of your LDAP configuration?
We are using CAS 3.x and usin OpenLDAP so it is not necessarily a good match, 
but our settings look like:

# == LDAP Authentication settings ==
ldap.authentication.filter=uid=%u
ldap.authentication.server.urls=ldaps://ldap.lafayette.edu
ldap.authentication.basedn=O=lafayette
ldap.authentication.manager.userdn=cn=casbrowser,o=lafayette
ldap.authentication.manager.password=REDACTED
ldap.authentication.ignorePartialResultException=true
ldap.authentication.scope=2
ldap.authentication.jndi.connect.timeout=3000
ldap.authentication.jndi.read.timeout=3000
ldap.authentication.jndi.security.level=simple


Thanks,
Carl

- Original Message -
From: "Mike Seiler" 
To: cas-user@lists.jasig.org
Sent: Tuesday, June 30, 2015 2:44:32 PM
Subject: Re: [cas-user] Help with CAS 4.0 & AD

The AD is set to allow global search by all authenticated users; any thing
else (resetting password, etc) requires the administrator credentials - but
we don't use the Password Manager in CAS - we do that externally via other
apps.  All we need is to determine that a user's account authenticates and
pass the attributes on to other applications.

I'm using the deployerConfigContext defined here:
http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
(The first code sample, which says "The following configuration
authenticates users by sAMAccountName without performing a search, which
requires manager/administrator credentials in most cases. It is therefore
the most performant and secure solution for the typical Active Directory
deployment.")

*From the command line:* I am able to do an ldapsearch using my own
credentials (and looking up another user), and, of course, I am also able
to do a search for another user using the Admin credentials:

ldapsearch -x -H ldaps://id.fuller.edu  -b
"ou=fuller,dc=id,dc=fuller,dc=edu" -D "admin_acco...@id.fuller.edu" -w
"admin_password" "(sAMAccountName=michaelseiler)" cn sn displayName
sAMAccountName pwdLastSet lastLogon mail memberof

With either the admin credentials or my own, I get all requested data back
from the server, but with CAS the validation of my own personal account
credentials fails, and all I can seem to get from the error logs is that my
own personal credentials are invalid -- even though I can use them from the
command line and retrieve data for any user.

It seems that this is a configuration error in CAS, but the error logs are
insufficient to help debug this.

Setting up a proxy to track down issues is beyond my knowledge.  If there
is other documentation on setting up CAS 4.0 with LDAP that doesn't use the
Maven overlay method or the cut-and-paste code from the above URL, I'd be
happy to try that out at this point.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
waldb...@lafayette.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

RE: [cas-user] Help with CAS 4.0 & AD

[Danner, Mearl]

Without using a proxy is it possible to use ldap rather than ldaps? Unless your 
admins have specified otherwise you only need ldaps for password changes.

Using plain ldap you can run tshark from the CAS server console to get a packet 
trace you can look at in Wireshark.

The packet trace should show where it's failing.

Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-Original Message-
From: Mike Seiler [michaelsei...@fuller.edu]
Received: Tuesday, 30 Jun 2015, 1:44PM
To: cas-user@lists.jasig.org [cas-user@lists.jasig.org]
Subject: Re: [cas-user] Help with CAS 4.0 & AD

The AD is set to allow global search by all authenticated users; any thing else 
(resetting password, etc) requires the administrator credentials - but we don't 
use the Password Manager in CAS - we do that externally via other apps.  All we 
need is to determine that a user's account authenticates and pass the 
attributes on to other applications.

I'm using the deployerConfigContext defined here:
http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
(The first code sample, which says "The following configuration authenticates 
users by sAMAccountName without performing a search, which requires 
manager/administrator credentials in most cases. It is therefore the most 
performant and secure solution for the typical Active Directory deployment.")

>From the command line: I am able to do an ldapsearch using my own credentials 
>(and looking up another user), and, of course, I am also able to do a search 
>for another user using the Admin credentials:

ldapsearch -x -H ldaps://id.fuller.edu<http://id.fuller.edu>  -b 
"ou=fuller,dc=id,dc=fuller,dc=edu" -D 
"admin_acco...@id.fuller.edu<mailto:admin_acco...@id.fuller.edu>" -w 
"admin_password" "(sAMAccountName=michaelseiler)" cn sn displayName 
sAMAccountName pwdLastSet lastLogon mail memberof

With either the admin credentials or my own, I get all requested data back from 
the server, but with CAS the validation of my own personal account credentials 
fails, and all I can seem to get from the error logs is that my own personal 
credentials are invalid -- even though I can use them from the command line and 
retrieve data for any user.

It seems that this is a configuration error in CAS, but the error logs are 
insufficient to help debug this.

Setting up a proxy to track down issues is beyond my knowledge.  If there is 
other documentation on setting up CAS 4.0 with LDAP that doesn't use the Maven 
overlay method or the cut-and-paste code from the above URL, I'd be happy to 
try that out at this point.


--
You are currently subscribed to cas-user@lists.jasig.org as: 
jmdan...@samford.edu
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

The AD is set to allow global search by all authenticated users; any thing
else (resetting password, etc) requires the administrator credentials - but
we don't use the Password Manager in CAS - we do that externally via other
apps.  All we need is to determine that a user's account authenticates and
pass the attributes on to other applications.

I'm using the deployerConfigContext defined here:
http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
(The first code sample, which says "The following configuration
authenticates users by sAMAccountName without performing a search, which
requires manager/administrator credentials in most cases. It is therefore
the most performant and secure solution for the typical Active Directory
deployment.")

*From the command line:* I am able to do an ldapsearch using my own
credentials (and looking up another user), and, of course, I am also able
to do a search for another user using the Admin credentials:

ldapsearch -x -H ldaps://id.fuller.edu  -b
"ou=fuller,dc=id,dc=fuller,dc=edu" -D "admin_acco...@id.fuller.edu" -w
"admin_password" "(sAMAccountName=michaelseiler)" cn sn displayName
sAMAccountName pwdLastSet lastLogon mail memberof

With either the admin credentials or my own, I get all requested data back
from the server, but with CAS the validation of my own personal account
credentials fails, and all I can seem to get from the error logs is that my
own personal credentials are invalid -- even though I can use them from the
command line and retrieve data for any user.

It seems that this is a configuration error in CAS, but the error logs are
insufficient to help debug this.

Setting up a proxy to track down issues is beyond my knowledge.  If there
is other documentation on setting up CAS 4.0 with LDAP that doesn't use the
Maven overlay method or the cut-and-paste code from the above URL, I'd be
happy to try that out at this point.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Help with CAS 4.0 & AD

[Waldbieser, Carl]

Mike,

Are you sure it is not some kind of ACL issue on the AD side?
When one account can cause the system to behave correctly but another cannot, 
it usually boils down to a permission issue.

If LDAP logs are inaccessible or difficult to decipher, I sometimes insert an 
LDAP proxy between my LDAP client and LDAP server.  I can crank up logging on 
the proxy to determine what interactions are taking place and what might be 
going wrong.

The basic troubleshooting technique is to compare the logs that work (manager 
account) to the logs that fail (normal service DN) and try to determine what 
requests may not have sufficient permissions under that account.

Thanks,
Carl

- Original Message -
From: "Mike Seiler" 
To: cas-user@lists.jasig.org
Sent: Monday, June 29, 2015 1:28:59 PM
Subject: Re: [cas-user] Help with CAS 4.0 & AD

Any further suggestions on what might be causing the system to fail to
authenticate users?

Bind with manager password works. Certificates validate. sAMAccountName is
set as the search filter.

Any suggestions would be appreciated.


On Wed, Jun 24, 2015 at 8:26 AM, Mike Seiler 
wrote:

> Daniel,
>
> Thanks for your your response.  I redeployed so that my log files would be
> fresh.  I've attached the localhost log, the cas.log, and the catalina.out
> file to this email.
>
> Catalina.out has an enormous amount of DEBUG info; I hope it doesn't get
> in the way.  I also deleted things before the system started loading secure
> certificates and connecting to the AD server (if you need the entire log,
> let me know and I'll resend).  The cas and localhost logs don't seem to
> contain much at all.
>
> If it helps shed some light, I built my system using this Git Repo:
> https://github.com/UniconLabs/simple-cas4-overlay-template
>
> And then added in the AD layer using this documentation:
>
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
>
> Thanks,
>
> Mike
>
> On Wed, Jun 24, 2015 at 6:39 AM, Daniel Fisher  wrote:
>
>> On Tue, Jun 23, 2015 at 6:33 PM, Mike Seiler 
>> wrote:
>>
>>> Daniel,
>>>
>>> Thanks.  I turned on the debug for Ldaptive, and got multiple lines of
>>> DEBUG, but none seems to indicate a full error that I can see.
>>>
>>> If I manually set useSSL to true (in deployerConfigContext), the
>>> application initializes fine and cas.log still shows "authentication
>>> failed" but there are no other errors to indicate that something is wrong
>>> either in catalina.out or cas.log.
>>>
>>
>> Sounds like your properties aren't being applied to the
>> deployerConfigContext.xml.
>>
>>
>>
>>> The lines containing the useSSL and useStartTLS:
>>> ---
>>> 2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool]
>>> - >> [org.ldaptive.pool.Queue@458045035::queueType=LIFO,
>>> queue=[org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@6a3096d4,
>>> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@630eaf38,
>>> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@2021f8cc
>>> ]]>
>>> 2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool]
>>> - >> [org.ldaptive.pool.BlockingConnectionPool@1188516673::name=null,
>>> poolConfig=[org.ldaptive.pool.PoolConfig@1654322364::minPoolSize=3,
>>> maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false,
>>> validatePeriodically=true, validatePeriod=300], activator=null,
>>> passivator=null, validator=[org.ldaptive.pool.SearchValidator@725194039
>>> ::searchRequest=[org.ldaptive.SearchRequest@88681342::*baseDn=,
>>> searchFilter=*[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*),
>>> parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=0,
>>> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
>>> sortBehavior=UNORDERED, searchEntryHandlers=null,
>>> searchReferenceHandlers=null, controls=null, followReferrals=false,
>>> intermediateResponseHandlers=null]]
>>> pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@397920599::prunePeriod=300,
>>> idleTime=600], connectOnCreate=true,
>>> connectionFactory=[org.ldaptive.DefaultConnectionFactory@587430635
>>> ::provider=org.ldaptive.provider.jndi.JndiProvider@397aec42,
>>> config=[org.ldaptive.ConnectionConfig@892141193::ldapUrl=ldap://
>>> id.fuller.edu:636, connectTimeout=3000, responseTimeout=-1,
>>> sslConfig=[org.ldaptive.ssl.Ss

Re: [cas-user] Help with CAS 4.0 & AD

[Daniel Fisher]

On Mon, Jun 29, 2015 at 1:28 PM, Mike Seiler 
wrote:

> Any further suggestions on what might be causing the system to fail to
> authenticate users?
>
> Bind with manager password works. Certificates validate. sAMAccountName is
> set as the search filter.
>
> Any suggestions would be appreciated.
>

I didn't see the LDAP authentication component being exercised. Your LDAP
pools initialize correctly, but the authentication handler does not appear
to use them. I don't know enough about the v4 config to say what's wrong,
but I would look for something fundamental in the authentication wiring,
not in the LDAP config.

--Daniel Fisher

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Any further suggestions on what might be causing the system to fail to
authenticate users?

Bind with manager password works. Certificates validate. sAMAccountName is
set as the search filter.

Any suggestions would be appreciated.


On Wed, Jun 24, 2015 at 8:26 AM, Mike Seiler 
wrote:

> Daniel,
>
> Thanks for your your response.  I redeployed so that my log files would be
> fresh.  I've attached the localhost log, the cas.log, and the catalina.out
> file to this email.
>
> Catalina.out has an enormous amount of DEBUG info; I hope it doesn't get
> in the way.  I also deleted things before the system started loading secure
> certificates and connecting to the AD server (if you need the entire log,
> let me know and I'll resend).  The cas and localhost logs don't seem to
> contain much at all.
>
> If it helps shed some light, I built my system using this Git Repo:
> https://github.com/UniconLabs/simple-cas4-overlay-template
>
> And then added in the AD layer using this documentation:
>
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
>
> Thanks,
>
> Mike
>
> On Wed, Jun 24, 2015 at 6:39 AM, Daniel Fisher  wrote:
>
>> On Tue, Jun 23, 2015 at 6:33 PM, Mike Seiler 
>> wrote:
>>
>>> Daniel,
>>>
>>> Thanks.  I turned on the debug for Ldaptive, and got multiple lines of
>>> DEBUG, but none seems to indicate a full error that I can see.
>>>
>>> If I manually set useSSL to true (in deployerConfigContext), the
>>> application initializes fine and cas.log still shows "authentication
>>> failed" but there are no other errors to indicate that something is wrong
>>> either in catalina.out or cas.log.
>>>
>>
>> Sounds like your properties aren't being applied to the
>> deployerConfigContext.xml.
>>
>>
>>
>>> The lines containing the useSSL and useStartTLS:
>>> ---
>>> 2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool]
>>> - >> [org.ldaptive.pool.Queue@458045035::queueType=LIFO,
>>> queue=[org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@6a3096d4,
>>> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@630eaf38,
>>> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@2021f8cc
>>> ]]>
>>> 2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool]
>>> - >> [org.ldaptive.pool.BlockingConnectionPool@1188516673::name=null,
>>> poolConfig=[org.ldaptive.pool.PoolConfig@1654322364::minPoolSize=3,
>>> maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false,
>>> validatePeriodically=true, validatePeriod=300], activator=null,
>>> passivator=null, validator=[org.ldaptive.pool.SearchValidator@725194039
>>> ::searchRequest=[org.ldaptive.SearchRequest@88681342::*baseDn=,
>>> searchFilter=*[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*),
>>> parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=0,
>>> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
>>> sortBehavior=UNORDERED, searchEntryHandlers=null,
>>> searchReferenceHandlers=null, controls=null, followReferrals=false,
>>> intermediateResponseHandlers=null]]
>>> pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@397920599::prunePeriod=300,
>>> idleTime=600], connectOnCreate=true,
>>> connectionFactory=[org.ldaptive.DefaultConnectionFactory@587430635
>>> ::provider=org.ldaptive.provider.jndi.JndiProvider@397aec42,
>>> config=[org.ldaptive.ConnectionConfig@892141193::ldapUrl=ldap://
>>> id.fuller.edu:636, connectTimeout=3000, responseTimeout=-1,
>>> sslConfig=[org.ldaptive.ssl.SslConfig@486207397
>>> ::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@1427787790::trustCertificates=file:/etc/cas/id_app.pem,
>>> authenticationCertificate=null, authenticationKey=null],
>>> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null,
>>> handshakeCompletedListeners=null], *useSSL=true, useStartTLS=false*,
>>> connectionInitializer=null]], initialized=false, availableCount=3,
>>> activeCount=0]>
>>>
>>
>> Your connection pool initialized successfully. You're likely having DN
>> resolution issues, which may be further indication that your properties
>> aren't being applied. If you post an entire log from a single
>> authentication attempt I can probably point to the problem.
>>
>> --Daniel Fisher
>>
>> --
>> You are currently subscribed to cas-user@lists.jasig.org as: 
>> michaelsei...@fuller.edu
>> To unsubscribe, change settings or access archives, see 
>> http://www.ja-sig.org/wiki/display/JSG/cas-user
>>
>>
>
>
> --
> *Michael Seiler*
> --
> Systems Integration Engineer
> Fuller Theological Seminary
> Phone: (970) 306-6105
> michaelsei...@fuller.edu
>
> *Please NOTE:*
> I respond to email at 8 AM, 1PM, and at 4:30PM.  If you need more
> immediate help, please contact TSS (626.584.5675) and they can route the
> issue to the appropriate person.  If this is a business process li

Re: [cas-user] Help with CAS 4.0 & AD

[Daniel Fisher]

On Tue, Jun 23, 2015 at 6:33 PM, Mike Seiler 
wrote:

> Daniel,
>
> Thanks.  I turned on the debug for Ldaptive, and got multiple lines of
> DEBUG, but none seems to indicate a full error that I can see.
>
> If I manually set useSSL to true (in deployerConfigContext), the
> application initializes fine and cas.log still shows "authentication
> failed" but there are no other errors to indicate that something is wrong
> either in catalina.out or cas.log.
>

Sounds like your properties aren't being applied to the
deployerConfigContext.xml.



> The lines containing the useSSL and useStartTLS:
> ---
> 2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool] -
>  [org.ldaptive.pool.Queue@458045035::queueType=LIFO,
> queue=[org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@6a3096d4,
> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@630eaf38,
> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@2021f8cc
> ]]>
> 2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool] -
>  [org.ldaptive.pool.BlockingConnectionPool@1188516673::name=null,
> poolConfig=[org.ldaptive.pool.PoolConfig@1654322364::minPoolSize=3,
> maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false,
> validatePeriodically=true, validatePeriod=300], activator=null,
> passivator=null, validator=[org.ldaptive.pool.SearchValidator@725194039
> ::searchRequest=[org.ldaptive.SearchRequest@88681342::*baseDn=,
> searchFilter=*[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*),
> parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=0,
> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
> sortBehavior=UNORDERED, searchEntryHandlers=null,
> searchReferenceHandlers=null, controls=null, followReferrals=false,
> intermediateResponseHandlers=null]]
> pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@397920599::prunePeriod=300,
> idleTime=600], connectOnCreate=true,
> connectionFactory=[org.ldaptive.DefaultConnectionFactory@587430635
> ::provider=org.ldaptive.provider.jndi.JndiProvider@397aec42,
> config=[org.ldaptive.ConnectionConfig@892141193::ldapUrl=ldap://
> id.fuller.edu:636, connectTimeout=3000, responseTimeout=-1,
> sslConfig=[org.ldaptive.ssl.SslConfig@486207397
> ::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@1427787790::trustCertificates=file:/etc/cas/id_app.pem,
> authenticationCertificate=null, authenticationKey=null],
> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null,
> handshakeCompletedListeners=null], *useSSL=true, useStartTLS=false*,
> connectionInitializer=null]], initialized=false, availableCount=3,
> activeCount=0]>
>

Your connection pool initialized successfully. You're likely having DN
resolution issues, which may be further indication that your properties
aren't being applied. If you post an entire log from a single
authentication attempt I can probably point to the problem.

--Daniel Fisher

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Thanks Carl,

That was actually a leftover from testing.  I had tried every option of
connection setting, even the ones that don't make sense (like
ldaps://host:389 and ldap://host:636); neither of those two worked, of
course.  However, even with ldaps://id.fuller.edu or ldaps://
id.fuller.edu:636 I still get "Invalid Credentials."

I've added DEBUG levels to most everything that pertains to LDAP, and I'm
still not seeing any errors listed that seem to shed light.

Just as additional info, I noticed that the cas.log in the production
server shows the following:
=
WHO: [username: michaelseiler]
WHAT: supplied credentials: [username: michaelseiler]
ACTION: AUTHENTICATION_SUCCESS
APPLICATION: CAS
WHEN: Tue Jun 23 22:19:05 PDT 2015
CLIENT IP ADDRESS: 65.129.164.219
SERVER IP ADDRESS: 192.168.72.137
=

and the test server seems to be missing the username in the "WHO" section:
=
WHO: audit:unknown
WHAT: supplied credentials: [michaelseiler+password]
ACTION: AUTHENTICATION_FAILED
APPLICATION: CAS
WHEN: Tue Jun 23 21:09:15 PDT 2015
CLIENT IP ADDRESS: 192.168.72.69
SERVER IP ADDRESS: 192.168.72.160
=

Not sure if that is an expected difference in CAS 4.0. or not.

Thanks,

Mike

On Tue, Jun 23, 2015 at 4:09 PM, Carl Waldbieser 
wrote:

> If you are running on port 636, that typically is ldaps.  The initial tcp
> connection is encrypted using SSL/TLS and you would use STARTTLS=false and
> USETLS=true.
>
> The url scheme is "ldaps://host:port/basedn" for many ldap libraries (not
> sure about this one).
>
> Carl Waldbieser
>  On Jun 23, 2015 6:33 PM, "Mike Seiler"  wrote:
>
>> Daniel,
>>
>> Thanks.  I turned on the debug for Ldaptive, and got multiple lines of
>> DEBUG, but none seems to indicate a full error that I can see.
>>
>> In catalina.out there are a few lines about ldaptive that show the
>> following:
>> useSSL=false, useStartTLS=false,... etc.
>>
>> If I set the ldap.useStartTLS=true in my cas.properties, the application
>> fails to load and tells me that "TLS or SSL already in effect" and then
>> there's a cascading set of errors concerning initializing authentication
>> handlers.
>>
>> If I set ldap.useStartTLS=false, then the application loads fine, but
>> catalina.out shows that useSSL=false as well.
>>
>> If I manually set useSSL to true (in deployerConfigContext), the
>> application initializes fine and cas.log still shows "authentication
>> failed" but there are no other errors to indicate that something is wrong
>> either in catalina.out or cas.log.
>>
>> The following is from catalina.out which tells me SSL is loading properly:
>> ---
>> 2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>> > succeeded>
>> 2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier]
>> - 
>> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier]
>> - > ID]>
>> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier]
>> - 
>> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>> > org.ldaptive.ssl.HostnameVerifyingTrustManager@126d0169 succeeded>
>> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>> > sun.security.ssl.X509TrustManagerImpl@23802df5>
>> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>> > org.ldaptive.ssl.HostnameVerifyingTrustManager@126d0169>
>>
>> The lines containing the useSSL and useStartTLS:
>> ---
>> 2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool]
>> - > [org.ldaptive.pool.Queue@458045035::queueType=LIFO,
>> queue=[org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@6a3096d4,
>> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@630eaf38,
>> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@2021f8cc
>> ]]>
>> 2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool]
>> - > [org.ldaptive.pool.BlockingConnectionPool@1188516673::name=null,
>> poolConfig=[org.ldaptive.pool.PoolConfig@1654322364::minPoolSize=3,
>> maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false,
>> validatePeriodically=true, validatePeriod=300], activator=null,
>> passivator=null, validator=[org.ldaptive.pool.SearchValidator@725194039
>> ::searchRequest=[org.ldaptive.SearchRequest@88681342::*baseDn=,
>> searchFilter=*[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*),
>> parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=0,
>> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
>> sortBehavior=UNORDERED, searchEntryHandlers=null,
>> searchReferenceHandlers=null, controls=null, followReferrals=false,
>> i

Re: [cas-user] Help with CAS 4.0 & AD

[Carl Waldbieser]

If you are running on port 636, that typically is ldaps.  The initial tcp
connection is encrypted using SSL/TLS and you would use STARTTLS=false and
USETLS=true.

The url scheme is "ldaps://host:port/basedn" for many ldap libraries (not
sure about this one).

Carl Waldbieser
 On Jun 23, 2015 6:33 PM, "Mike Seiler"  wrote:

> Daniel,
>
> Thanks.  I turned on the debug for Ldaptive, and got multiple lines of
> DEBUG, but none seems to indicate a full error that I can see.
>
> In catalina.out there are a few lines about ldaptive that show the
> following:
> useSSL=false, useStartTLS=false,... etc.
>
> If I set the ldap.useStartTLS=true in my cas.properties, the application
> fails to load and tells me that "TLS or SSL already in effect" and then
> there's a cascading set of errors concerning initializing authentication
> handlers.
>
> If I set ldap.useStartTLS=false, then the application loads fine, but
> catalina.out shows that useSSL=false as well.
>
> If I manually set useSSL to true (in deployerConfigContext), the
> application initializes fine and cas.log still shows "authentication
> failed" but there are no other errors to indicate that something is wrong
> either in catalina.out or cas.log.
>
> The following is from catalina.out which tells me SSL is loading properly:
> ---
> 2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>  succeeded>
> 2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] -
> 
> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] -
>  ID]>
> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] -
> 
> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>  org.ldaptive.ssl.HostnameVerifyingTrustManager@126d0169 succeeded>
> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>  sun.security.ssl.X509TrustManagerImpl@23802df5>
> 2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -
>  org.ldaptive.ssl.HostnameVerifyingTrustManager@126d0169>
>
> The lines containing the useSSL and useStartTLS:
> ---
> 2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool] -
>  [org.ldaptive.pool.Queue@458045035::queueType=LIFO,
> queue=[org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@6a3096d4,
> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@630eaf38,
> org.ldaptive.pool.AbstractConnectionPool$DefaultPooledConnectionProxy@2021f8cc
> ]]>
> 2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool] -
>  [org.ldaptive.pool.BlockingConnectionPool@1188516673::name=null,
> poolConfig=[org.ldaptive.pool.PoolConfig@1654322364::minPoolSize=3,
> maxPoolSize=10, validateOnCheckIn=false, validateOnCheckOut=false,
> validatePeriodically=true, validatePeriod=300], activator=null,
> passivator=null, validator=[org.ldaptive.pool.SearchValidator@725194039
> ::searchRequest=[org.ldaptive.SearchRequest@88681342::*baseDn=,
> searchFilter=*[org.ldaptive.SearchFilter@1642584434::filter=(objectClass=*),
> parameters={}], returnAttributes=[1.1], searchScope=OBJECT, timeLimit=0,
> sizeLimit=1, derefAliases=null, typesOnly=false, binaryAttributes=null,
> sortBehavior=UNORDERED, searchEntryHandlers=null,
> searchReferenceHandlers=null, controls=null, followReferrals=false,
> intermediateResponseHandlers=null]]
> pruneStrategy=[org.ldaptive.pool.IdlePruneStrategy@397920599::prunePeriod=300,
> idleTime=600], connectOnCreate=true,
> connectionFactory=[org.ldaptive.DefaultConnectionFactory@587430635
> ::provider=org.ldaptive.provider.jndi.JndiProvider@397aec42,
> config=[org.ldaptive.ConnectionConfig@892141193::ldapUrl=ldap://
> id.fuller.edu:636, connectTimeout=3000, responseTimeout=-1,
> sslConfig=[org.ldaptive.ssl.SslConfig@486207397
> ::credentialConfig=[org.ldaptive.ssl.X509CredentialConfig@1427787790::trustCertificates=file:/etc/cas/id_app.pem,
> authenticationCertificate=null, authenticationKey=null],
> trustManagers=null, enabledCipherSuites=null, enabledProtocols=null,
> handshakeCompletedListeners=null], *useSSL=true, useStartTLS=false*,
> connectionInitializer=null]], initialized=false, availableCount=3,
> activeCount=0]>
>
> I notice that the baseDN is empty, though I have that set in my
> cas.properties file as per the file sample on the Active Directory
> Installation page.
>
> Just to verify my credentials, I logged in on our current CAS 3.5.2 server
> using the same credentials I am trying on the new 4.0 server - both CAS
> servers access the same Active Directory.
>
> Thanks,
>
> Mike
>
> On Tue, Jun 23, 2015 at 12:33 PM, Daniel Fisher  wrote:
>
>> On Tue, Jun 23, 2015 at 12:01 PM, Mike Seiler 
>> wrote:
>>
>>> Hello all,
>>>
>>> I'm running into problems authenticating with Active Directory in CAS
>>> 4.0.  What I've done so far:
>>> 1) set up the CAS server using this documentation:
>>> http://jasig.gi

Re: [cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Daniel,

Thanks.  I turned on the debug for Ldaptive, and got multiple lines of
DEBUG, but none seems to indicate a full error that I can see.

In catalina.out there are a few lines about ldaptive that show the
following:
useSSL=false, useStartTLS=false,... etc.

If I set the ldap.useStartTLS=true in my cas.properties, the application
fails to load and tells me that "TLS or SSL already in effect" and then
there's a cascading set of errors concerning initializing authentication
handlers.

If I set ldap.useStartTLS=false, then the application loads fine, but
catalina.out shows that useSSL=false as well.

If I manually set useSSL to true (in deployerConfigContext), the
application initializes fine and cas.log still shows "authentication
failed" but there are no other errors to indicate that something is wrong
either in catalina.out or cas.log.

The following is from catalina.out which tells me SSL is loading properly:
---
2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -

2015-06-23 15:12:46,290 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] -

2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] -

2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.DefaultHostnameVerifier] -

2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -

2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -

2015-06-23 15:12:46,300 DEBUG [org.ldaptive.ssl.AggregateTrustManager] -


The lines containing the useSSL and useStartTLS:
---
2015-06-23 15:12:46,814 DEBUG [org.ldaptive.pool.BlockingConnectionPool] -

2015-06-23 15:12:46,820 DEBUG [org.ldaptive.pool.BlockingConnectionPool] -


I notice that the baseDN is empty, though I have that set in my
cas.properties file as per the file sample on the Active Directory
Installation page.

Just to verify my credentials, I logged in on our current CAS 3.5.2 server
using the same credentials I am trying on the new 4.0 server - both CAS
servers access the same Active Directory.

Thanks,

Mike

On Tue, Jun 23, 2015 at 12:33 PM, Daniel Fisher  wrote:

> On Tue, Jun 23, 2015 at 12:01 PM, Mike Seiler 
> wrote:
>
>> Hello all,
>>
>> I'm running into problems authenticating with Active Directory in CAS
>> 4.0.  What I've done so far:
>> 1) set up the CAS server using this documentation:
>> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
>> 2) Installed secure certificates in Tomcat for both SSL (on 8443) and the
>> AD certificate
>> 3) Installed the certs in the default Java Keystore as well - when things
>> didn't work with only Tomcat certs
>> 4) Updated my cas.properties file with the appropriate credentials and
>> attributes.
>>
>> *The Problem:*
>> CAS loads, but returns with "Invalid Credentials" for every attempt to
>> log in (even though I can query the AD from the command line):
>>
>
> Put the org.ldaptive package in debug. That may shed some light on the
> problem.
>
> --Daniel Fisher
>
> --
> You are currently subscribed to cas-user@lists.jasig.org as: 
> michaelsei...@fuller.edu
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
>
>


-- 
*Michael Seiler*
--
Systems Integration Engineer
Fuller Theological Seminary
Phone: (970) 306-6105
michaelsei...@fuller.edu

*Please NOTE:*
I respond to email at 8 AM, 1PM, and at 4:30PM.  If you need more immediate
help, please contact TSS (626.584.5675) and they can route the issue to the
appropriate person.  If this is a business process life or death emergency,
you may call me at the above number.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Re: [cas-user] Help with CAS 4.0 & AD

[Daniel Fisher]

On Tue, Jun 23, 2015 at 12:01 PM, Mike Seiler 
wrote:

> Hello all,
>
> I'm running into problems authenticating with Active Directory in CAS
> 4.0.  What I've done so far:
> 1) set up the CAS server using this documentation:
> http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
> 2) Installed secure certificates in Tomcat for both SSL (on 8443) and the
> AD certificate
> 3) Installed the certs in the default Java Keystore as well - when things
> didn't work with only Tomcat certs
> 4) Updated my cas.properties file with the appropriate credentials and
> attributes.
>
> *The Problem:*
> CAS loads, but returns with "Invalid Credentials" for every attempt to log
> in (even though I can query the AD from the command line):
>

Put the org.ldaptive package in debug. That may shed some light on the
problem.

--Daniel Fisher

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

[cas-user] Help with CAS 4.0 & AD

[Mike Seiler]

Hello all,

I'm running into problems authenticating with Active Directory in CAS 4.0.
What I've done so far:
1) set up the CAS server using this documentation:
http://jasig.github.io/cas/4.0.x/installation/LDAP-Authentication.html#active_directory_authentication
2) Installed secure certificates in Tomcat for both SSL (on 8443) and the
AD certificate
3) Installed the certs in the default Java Keystore as well - when things
didn't work with only Tomcat certs
4) Updated my cas.properties file with the appropriate credentials and
attributes.

*The Problem:*
CAS loads, but returns with "Invalid Credentials" for every attempt to log
in (even though I can query the AD from the command line):

*cas.log* file only shows:
2015-06-23 08:45:14,945 INFO
[org.jasig.cas.web.flow.InitialFlowSetupAction] - Setting path for cookies
to: /cas/
2015-06-23 08:45:14,945 INFO
[org.jasig.cas.web.flow.InitialFlowSetupAction] - Setting path for cookies
to: /cas/
2015-06-23 08:45:23,607 INFO
[com.github.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - Audit
trail record BEGIN
=
WHO: audit:unknown
WHAT: supplied credentials: [michaelseiler+password]
ACTION: AUTHENTICATION_FAILED
APPLICATION: CAS
WHEN: Tue Jun 23 08:45:23 PDT 2015
CLIENT IP ADDRESS: 192.168.72.69
SERVER IP ADDRESS: 192.168.72.160
=

*catalina.out* only shows the following:
2015-06-23 08:45:23,625 DEBUG
[org.springframework.webflow.execution.repository.impl.DefaultFlowExecutionRepository]
-  [null], 'warnCookieValue' ->
false, 'credential' -> michaelseiler+password, 'ticketGrantingTicketId' ->
[null], 'viewScope' -> map['commandName' -> 'credential'], 'loginTicket' ->
'LT-2-cVte4SctmZucdLkHSNzw0e3mbTgtpi-logintest.fuller.edu'' into
repository>

*Debugging/Troubleshooting:*
1) The credentials I am using are correct, as I log in with those
credentials currently.
2) From the command line with an *ldapsearch* I am able to retrieve the
data concerning my account using the same credentials for Admin + Password
that I set in the *cas.properties* file.

It seems I'm missing something that is keeping my CAS install from actually
talking to the AD server.

I'm at a point where I'm going circular in my Google searches, so any help
or pointers to additional resources would be appreciated.

Thanks,

Mike
-- 
*Michael Seiler*
--
Systems Integration Engineer
Fuller Theological Seminary
Phone: (970) 306-6105
michaelsei...@fuller.edu

*Please NOTE:*
I respond to email at 8 AM, 1PM, and at 4:30PM.  If you need more immediate
help, please contact TSS (626.584.5675) and they can route the issue to the
appropriate person.  If this is a business process life or death emergency,
you may call me at the above number.

-- 
You are currently subscribed to cas-user@lists.jasig.org as: 
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user