Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

RADIUS: MSCHAP: AD status:No trusted SAM account (0xc000018b)

This thread has been viewed 28 times
  • 1.  RADIUS: MSCHAP: AD status:No trusted SAM account (0xc000018b)

    Posted Apr 13, 2016 07:35 PM

    Hello guys

     

    I have this issue that it´s happen in two different clients those have windows server 2012, I already did the process in this foro (http://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/CPPM-management-user-authentication-against-AD-fails-No-trusted/ta-p/185422) this process is the recommend by the Aruba’s TAC, when I did this process the issue is fix by for a short time, after this short time the issue appears again, my Clearpass’s version is 6.5.2.

     

    Do you have any recommendation to fix this issue, thanks.

     



  • 2.  RE: RADIUS: MSCHAP: AD status:No trusted SAM account (0xc000018b)

    EMPLOYEE
    Posted Apr 23, 2016 06:08 AM

    If you haven't already, you should contact TAC and let them know that the problem still exists...



  • 3.  RE: RADIUS: MSCHAP: AD status:No trusted SAM account (0xc000018b)

    EMPLOYEE
    Posted Apr 24, 2016 08:25 AM

    This message indicates that there is something wrong with the domain join of your ClearPass.

     

    I have seen windows administrators delete the computer account the ClearPass created (and requires to do MSCHAP authentication), so double check with your AD admins.

    You can check as well:

    - That ClearPass is configured to use the Active Directory DNS servers; that is needed to find the right domain controllers.

    - That time is set correct on both ClearPass and the domain controllers; use the domain controllers as NTP server to make sure they run the same time source.

    - That there are no firewall in between ClearPass and your domain controllers that might block the authentication traffic.

    - You can check from the appadmin (console) account the AD and kerberos servers:

    [appadmin@cppm.nl.arubalab.com]# ad auth -u herman -n nl
    password: 
    INFO -  NT_STATUS_OK: Success (0x0)
    [appadmin@cppm.nl.arubalab.com]# krb auth herman@nl.arubalab.com
    
    Using default cache: /tmp/krb5cc_0
    Using principal: herman@NL.ARUBALAB.COM
    Password for herman@NL.ARUBALAB.COM: 
    Authenticated to Kerberos v5

    And work with TAC if these do not fix your issue...