Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
New Member

Ironport S370 Authentication Realm problem

Hi All,

I'm trying to configure an Authentication Realm on an Ironport S370 running AsyncOS Version:          6.3.3-015. I keep getting the following errors when I test:

   Checking DNS resolution of WSA hostname(s)...

    Failure: Unable to resolve '****.****' :

    Unknown hostname

    Checking DNS resolution of Active Directory Server(s)...

    Success: Resolved '*********' address: ***

    Success: Resolved '*********' address: ***

    Checking DNS resolution of AD Server(s)' full computer name(s)...

    Success: Resolved '*******' address: *****

    Success: Resolved '*******' address: *****

    Validating configured Active Directory Domain...

    Success: Active Directory Domain Name for '*****' : *****

    Success: Active Directory Domain Name for '*****' : *****

    Attempting to get TGT...

    Failure: Error while fetching Kerberos Tickets from server '*****' :

    kinit: krb5_get_init_creds: Client (*****) unknown

    Failure: Error while fetching Kerberos Tickets from server '*****' :

    kinit: krb5_get_init_creds: Client (*****) unknown

    Checking local WSA time and server time difference...

    Success: AD Server time and WSA time difference within tolerance limit

    Success: AD Server time and WSA time difference within tolerance limit

    Attempting to fetch group information...

    Failure: Queries to server '*****' on port 389 failed :

    Server doesn't accept anonymous queries

    Failure: Queries to server '*****' on port 389 failed :

    Server doesn't accept anonymous queries

    Test completed: Errors occurred, see details above.

I've tried adding a DNS entry for the security appliance, but it still doesn't reslove. Any advice would be greatly appreciated.

10 REPLIES

Ironport S370 Authentication Realm problem

Have you joined the WSA to the domain yet?

You're getting this:

     Attempting to fetch group information...

    Failure: Queries to server '*****' on port 389 failed :

    Server doesn't accept anonymous queries

    Failure: Queries to server '*****' on port 389 failed :

    Server doesn't accept anonymous queries

because your domain doesn't allow anonymous queries... which means it doesn't know who your box is.

New Member

Ironport S370 Authentication Realm problem

I have same issue here with a fresh installed S370 trying to join Active Directory. I have also a Support Case opened, but no success yet. Trying to join the AD, the computer account $ is created (ldapcreate works), but deactivated (ldapmodify fails). I see here no valid user credential or priviledge issue in this step.

In Security Log of AD Controller the pre-authientication fails with kerberos. Analyzing the packet capture, I see some successful ldap binds but the query/modify fails with the error "successful bind required". Needless to say, that the wireshark shows the sucess/error message within 30ms.

As well there is an entry in Security Log NT Authority\System, Logon failure: Reason Unknown user name or bad password. User name: $

I believe (not able to be verified) it is a kerberos issue produced from the WSA. As all the traffic is initiated by management interface and pre-auth is required, some mis-interpretations occur. DNS entries for WSA Management & Data Interface are in place, PTR records are done.

Any support would be helpful, maybe also via Case SR619902851.

Ironport S370 Authentication Realm problem

Andy,

     Is the time on your WSA correct?  Kerberos is unhappy with too much time skew...

     What does the authlogs log file show if anything? (System/Log Subscriptions)

     Is DNS for your domain healthy?  All of the DC records where they need to be? (I've run a ipconfig /registerdns and restarted Netlogon to make sure all of the records are in place.)

     Run "dcdiag" each domain controller... and make sure its clean.

    

     Delete the machine the current machine account for the WSA, then recreate it.

     When you recreate it, put it in an OU you know isn't getting any weird rights propagated down on it...

     Check the Authlogs(assuming they give you any info...)

Ken

New Member

Re: Ironport S370 Authentication Realm problem

Hi Ken, thanks for the feedback!

time skew issues are figured out, because AD & WSA using the same NTP instances. AD seems clean, trusting my Domain Admins here (must to). registerdns & netlogon restart are done, dcdiag is ok, no further success yet.

The OU was changed several times by our repeating tests, the account creation itself works, but by using ldapmodify the computer account is deactivated and no logon is possible. Never got that issue with Active Directory.

Question: Is it an option to to pre-create the computer account manually? Do I need to use the same credentials as in the "createcomputerobject" script dialogue from WSA? Any special SPN or other attributes to be set, before I use "createcomputerobject"? Or is there any (hidden) ldapmodify on WSA command-set I can use to USE that pre-created account instead of creating a new & disabled one?

Thanks in advance!

P.S.: Which AES encryption is used by WSA for Kerberos?

P.P.S.: Issue solved: Account Type used was wrong used, changing attribute to 0x1100 solved the problem. s650 had no issue at all, s370 must have been altered manually and just a new AD Domain process started.

Ironport S370 Authentication Realm problem

Andy,

Glad to hear you figured out what the issue was...

Ken

New Member

Re: Ironport S370 Authentication Realm problem

Same thing here. on s170 with 7.1 or 7.5

is there a little more explenation?

was the computer account precreated and then modified the attribute or how was it excatly done?

New Member

Ironport S370 Authentication Realm problem

Sorry for my late answer as I didn't follow this topic anymore. But to clean up questions:

- Using S370

- Creating computer account by web-GUI with OU admin user, corrsponding the OU used in the menue dialogue

- by creating the account, it was immediately deactivated

- modifying manually in AD the account type to 0x1100 it worked

We use S650, S360 and S370 and only the S370 had this issue. Just added another S360 with the web-GUI it worked without any troubles. But of course, sethostname must reflect a proper DNS entry and the WSA hostnames configured on the physical ethernet interfaces are not used by the AD join process. Only hostname shown on SSH is used for all the naming resolutions by joining to domain.

New Member

We are also having problems

We are also having problems joining a new S390 to our domain (we have joined multiple S160's and S170's without a problem).

Please can you tell me exactly where you are changing 'account type'?

If I manually created the WSA 'computer' in AD, then look at the attribute editor, there is no attribute by this specific name.

Thank you.

New Member

Hi,

Hi,

value is used in user account control & cumulates the flags set.

New Member

Thank you, Andreas,

Thank you, Andreas,

It looks like, specifically, it's called 'userAccountControl' under the Computer AD object.

Unfortunately, still didn't work in our case.

Cheers.

12291
Views
0
Helpful
10
Replies
CreatePlease to create content