CLEANACCESS Archives

June 2007

CLEANACCESS@LISTSERV.MIAMIOH.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Osborne, Bruce W. (NS)" <[log in to unmask]>
Reply To:
Cisco Clean Access Users and Administrators <[log in to unmask]>
Date:
Fri, 22 Jun 2007 10:39:54 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
Howard,

That's exactly what I did in 4.0.5. I created an account for each DC.I
turned off SSo because of cached credentials issues. I am moving to
4.1.1 next week and expect to enable SSO against our domain. It is
working in our test environment now.

Bruce Osborne
Liberty University

-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Speight, Howard
Sent: Friday, June 22, 2007 10:25 AM
To: [log in to unmask]
Subject: [CLEANACCESS] AD SSO, CCA 4.0.5

Just an FYI, opened a TAC case...

The problem was KTPASS should only be run on one DC, preferably the PDC
emulator containing a copy of the global catalog. We ran it against four
DC's thinking if we lost the DC configured on the CAS for AD SSO
service, update to a working DC. This broke our original server setup
and the last server KTPASS was run on started working. The fix is to
upgrade to 4.1.1 which allows KTPASS against the domain. 

You could do this in the interim if upgrading to 4.1.1 is not an option.
Create ccasso1, ccasso2, ccasso3, ccasso4, etc, run KTPASS on each DC
with a different userid. If the DC configured on the CAS fails, update
the CAS with a working DC using the appropriate sso username and
password.

Thanks, Howard

ATOM RSS1 RSS2