Wow - thank you Michael!! :-)

Constance


Sent from iPhone 

On Apr 16, 2013, at 8:00 PM, "Michael A Grady" <[email protected]> wrote:

> The Shibboleth documentation has a nice section about port usage when 
> connecting to Active Directory for authentication/attributes. Even though you 
> are talking about accessing AD from a CAS Server, the notes in the Shib 
> documentation about the "ldap peculiarities" of AD still apply. Here's the 
> Shib page, look at the section labeled "Microsoft Active Directory". 
> 
>  https://wiki.shibboleth.net/confluence/display/SHIB2/LdapServerIssues
> 
> Here is the first part of that section of the above web page:
> 
>> Microsoft Active Directory
>> 
>> Port
>> Standard LDAP
>> If all users reside under the same single-depth object (e.g., 
>> CN=Users,DC=example,DC=edu), the standard ports can likely be used:
>> 
>>    • 389 for plain-old LDAP or LDAP with StartTLS. Note, StartTLS is only 
>> available on Windows Server 2003 and later.
>>    • 636 for LDAPS
>> Searches using the above connection information may encounter and need to 
>> handle referrals (see Referrals below).
>> 
>> Global Catalog
>> If users are spread across multiple object (e.g., CN=Staff,DC=example,DC=edu 
>> and CN=Faculty,DC=example,DC=edu) or if the standard connection method 
>> (above) doesn't work, the global catalog ports can be used:
>> 
>>    • 3268 for plain-old LDAP or LDAP with StartTLS. Note, StartTLS is only 
>> available on Windows Server 2003 and later.
>>    • 3269 for LDAPS
>> As a general note, the global catalog supports searches across the entire 
>> forest. Attributes that should be accessible to the Shibboleth IdP will have 
>> to be specified as part of the Partial Attribute Set (PAS) in Active 
>> Directory.
> 
> You would not normally need to connect to AD both thru the secure and 
> unsecure ports; sticking to the SSL (636 or 3269) port is more secure.
> 
> On Apr 16, 2013, at 6:47 PM, Constance Morris wrote:
> 
>> Hi Andy,
>> 
>> Thank you! May I confirm with you if I am understanding things?
>> What I am wanting to do with CAS is use it for SSO authentication into our 
>> school luminis portal and the additional resource links we provide to 
>> students from within the portal. That way, they will not be prompted to 
>> login to those additional resources once they have already logged into the 
>> portal. I had been thinking about also setting up Shibboleth in addition to 
>> CAS for a more secure SSO authentication.
>> 
>> So for:
>> 1.) I've got this based on what you said, but will CAS need to connect via 
>> port 389 at all or just strictly 636 to the LDAPS?
>> 
>> 2.) This possible database server - would that be Active Directory (AD)? 
>> While we have the luminis portal LDAP - we use Active Directory LDAP as our 
>> means of authentication currently into our luminis portal. 
>> 
>> 3.) What about port 8447 - I don't know the difference between the two but 
>> I've heard someone mention that one before for HTTPS type access.
>>     Would this be the same for other resources besides D2L like AdvisorTrac?
>> 
>> 4.) This is where I think someone mentioned port 8447 or 8090.
>> 
>> Thank you very much for responding! This helps a great deal.
>> 
>> Constance
>> 
>> Dalton State College
>> Portal Administrator
>> 
>> -----------------------------------
>> 
>> Some of the answers depend how you deploy CAS.  From the context you have
>> given, here is what I would guess:
>> 
>> 1. CAS server will need to access your RODC via LDAPS (port 636) to
>> validate authentication credentials and possibly retrieve attributes for
>> the user.
>> 
>> 2. CAS server may need to access a database server to track allowed
>> services, attributes to release, maintain sessions, etc.  This depends on
>> your CAS deployment choices.
>> 
>> 3. D2L will need to connect to your CAS server via HTTPS (usually port
>> 443) to validate the Service Ticket given to them by the user's browser.
>> 
>> 4. Your users will need to connect to the CAS server via HTTPS to interact
>> with CAS.
>> 
>>       Andy
> 
> 
> --
> Michael A. Grady
> Senior IAM Consultant, Unicon, Inc.
> 
> 
> -- 
> You are currently subscribed to [email protected] as: 
> [email protected]
> To unsubscribe, change settings or access archives, see 
> http://www.ja-sig.org/wiki/display/JSG/cas-user
> 

-- 
You are currently subscribed to [email protected] as: 
[email protected]
To unsubscribe, change settings or access archives, see 
http://www.ja-sig.org/wiki/display/JSG/cas-user

Reply via email to