Well, the solution was quite simple: disable the "Use DES encryption types
for this account" in the AD server for the CAS account. Why they just don't
put this in the documentation ???
Thanks.
Regards,
Antonio Soares, CCIE #18473 (R&S/SP)
[log in to unmask]
-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of Antonio Soares
Sent: sexta-feira, 26 de Novembro de 2010 13:04
To: [log in to unmask]
Subject: Re: NAC 4.8 SSO and WIN7
I opened a TAC case for this. I will update the list with the final
resolution of the problem.
Thanks.
Regards,
Antonio Soares, CCIE #18473 (R&S/SP)
[log in to unmask]
-----Original Message-----
From: Cisco Clean Access Users and Administrators
[mailto:[log in to unmask]] On Behalf Of daniel tumzghi
Sent: quarta-feira, 24 de Novembro de 2010 19:11
To: [log in to unmask]
Subject: Re: NAC 4.8 SSO and WIN7
Antonio,
I believe you need the "-crypto All" option on the ktpass command to
work with WIN7.
ktpass -princ newadsso/[adserver.][log in to unmask] -mapuser
newadsso -pass PasswordText -out c:\newadsso.keytab -ptype
KRB5_NT_PRINCIPAL -crypto All
Also, as annoying as it is, I was told to delete the ktpass file and
delete/recreate the user as well.
Regards,
/Daniel
On Wed, Nov 24, 2010 at 9:09 AM, James Strong (US)
<[log in to unmask]> wrote:
> I believe that it will corrupt the encryption if you run KTPASS more than
once for the came user. Try deleting the keytab file and then run KTPASS
again.
>
> -----Original Message-----
> From: Antonio Soares [mailto:[log in to unmask]]
> Sent: Tuesday, November 23, 2010 5:36 AM
> Subject: Re: NAC 4.8 SSO and WIN7
>
> Group,
>
> Do we really need to create a new CAS user in order to make it work ?
>
> How can I troubleshoot this ? The ktpass was executed without errors. But
> SSO still doesn't work for WIN7 users.
>
>
> Thanks.
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> [log in to unmask]
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Antonio Soares
> Sent: quarta-feira, 17 de Novembro de 2010 12:27
> To: [log in to unmask]
> Subject: Re: NAC 4.8 SSO and WIN7
>
> The customer tested only activating the RC4_HMAC_MD5 algorithm on the WIN7
> machines and it doesn't work. It works if the customer enables all the
> encryption methods available. This was expected since we enable DES this
> way.
>
> So most likely this means that the ktpass didn't work as expected. Can
> someone confirm that is the correct syntax:
>
> -------------------------
> For Windows 2003 Server at full functional level:
>
> ktpass -princ newadsso/[adserver.][log in to unmask] -mapuser newadsso
> -pass PasswordText -out c:\newadsso.keytab -ptype KRB5_NT_PRINCIPAL
> -------------------------
>
> The ktpass was executed without the [adserver.] option and we didn't see
any
> errors. As I mentioned, it was executed against the existing user. The
> documentation says to create a new user. But is this really mandatory ?
>
>
> Thanks.
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> [log in to unmask]
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Owens, DJ
> Sent: sexta-feira, 12 de Novembro de 2010 14:45
> To: [log in to unmask]
> Subject: Re: NAC 4.8 SSO and WIN7
>
> Antonio, for whatever reason when we tried to reuse the same account, SSO
> was failing. We ended up creating a new account, running the KTPass on
that
> one and it worked. TAC also immediately went to that resolution when we
> discussed with them. Good luck... D.J.
>
>
> D.J. Owens
> Senior Architect
> The Cincinnati Insurance Companies
> Office: (513) 870-2300 x4195
> Fax: (513) 881-8900
>
> CONFIDENTIAL COMMUNICATION:
> This message is intended for the use of the addressee,
> and may contain information that is protected by attorney-client
privilege.
> If you are not the intended recipient, any dissemination of this
> communication is strictly prohibited.
> If you have received this communication in error, please erase all the
> copies of this message and its attachments and notify the sender
> immediately.
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Antonio Soares
> Sent: Friday, November 12, 2010 8:55 AM
> To: [log in to unmask]
> Subject: Re: NAC 4.8 SSO and WIN7
>
> Hello Rob,
>
> We decided to run the ktpass against the existent cas user instead of
> creating a new one. The ktpass syntax used was exactly as mentioned in the
> CAS configuration guide:
>
> -------------------------
> For Windows 2003 Server at full functional level:
>
> ktpass -princ newadsso/[adserver.][log in to unmask] -mapuser newadsso
> -pass PasswordText -out c:\newadsso.keytab -ptype KRB5_NT_PRINCIPAL
> -------------------------
>
> Creating a new user is not mandatory for this to work I think. So it
should
> work but it still fails for WIN7 users.
>
> In the meanwhile, I asked the customer to see if they really have
> RC4_HMAC_MD5 enabled. It seems this should be on by default on all WIN7
> installations:
>
> http://technet.microsoft.com/en-us/library/dd560670%28WS.10%29.aspx
>
> But for example, my laptop doesn't show any algorithm enabled here:
>
> Control Panel > Administrative Tools > Local Security Policy > Local
> Policies > Security Options > Network security: Configure encryption types
> allowed for Kerberos
>
>
>
> Thanks.
>
> Regards,
>
> Antonio Soares, CCIE #18473 (R&S/SP)
> [log in to unmask]
>
>
> -----Original Message-----
> From: Cisco Clean Access Users and Administrators
> [mailto:[log in to unmask]] On Behalf Of Rob Chee
> Sent: sexta-feira, 12 de Novembro de 2010 11:27
> To: [log in to unmask]
> Subject: Re: NAC 4.8 SSO and WIN7
>
> Antonio,
>
> I've set this up successfully for a client using NAC 4.8 and Windows 2003
> domain controllers. They were running 4.8 and initially had the ktpass
> command with the +DesOnly at the end. When they introduced Windows 7
> machines into the network we found that AD SSO did not work for those
> computers. At that time we followed the instructions in the guide you
> posted. We created another AD user to assign to the AD SSO portion of the
> NAC server config. The ktpass command used for this user did not have the
> +DesOnly at the end. We then changed the NAC Servers to use the new AD
> user and everything worked correctly for both the Windows 7 and Windows XP
> computers.
>
> I have a little blog on why the +DesOnly is not required.
>
http://www.netcraftsmen.net/resources/blogs/cisco-nac-ad-sso-support-for-no
> n-des-encryption-types.html
>
> Are you sure the users had a valid Kerberos ticket? You can use
> kerbtray.exe on the end clients to verify that they weren't using cached
> credentials...
>
> Are you using ACLs to restrict the authentication VLAN? I've seen cases
> when one of the domain controllers was blocked by the authentication VLAN
> ACL, which caused problems similar to what you're seeing...
>
> ------------------------------------------------------
> Rob Chee, CCIE #8188 (R&S and Security)
> Senior Network Consultant
> Chesapeake NetCraftsmen, LLC.
> Company Website: http://www.netcraftsmen.net My Blog:
> http://www.netcraftsmen.net/resources/blogs/blogger/Rob%20Chee/
> Mobile: 571-437-2829
> ------------------------------------------------------
>
>
>
>
> On 11/10/10 7:59 AM, "Antonio Soares" <[log in to unmask]> wrote:
>
>>I have a customer that is running 4.8. The upgrade to this release was
>>made a few days ago. After running the procedure to support the Windows
>>7 clients, we see that SSO is not working. We are using ktpass version
>>5.2.3790.1830 and this is a Windows 2003 environment.
>>
>>The procedure is this one:
>>
>>http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_gu
>>ide
>>/4
>>8/cas/s_adsso.html#wp1277452
>>
>>The problem is that the users do the Windows authentication and the NAC
>>Agent window appears for login. SSO does not work for these users.
>>
>>Anyone has seen this problem before ?
>>
>>
>>Thanks.
>>
>>Regards,
>>
>>Antonio Soares, CCIE #18473 (R&S/SP)
>>[log in to unmask]
> -----------------------------------------
> Disclaimer:
>
> This e-mail communication and any attachments may contain
> confidential and privileged information and is for use by the
> designated addressee(s) named above only. If you are not the
> intended addressee, you are hereby notified that you have received
> this communication in error and that any use or reproduction of
> this email or its contents is strictly prohibited and may be
> unlawful. If you have received this communication in error, please
> notify us immediately by replying to this message and deleting it
> from your computer. Thank you.
>
|
