We recently upgraded our SA2000 to OS 6.2R1 (build 13255) from OS 6.0R5 (build 13073).
I am now seeing entries on almost every line of the event log saying "Cannot determine realm for AD server 4." This error did not start until just after the upgrade. Users are still able to log on without a problem. But this error must mean something.
I opened a case with JTAC, but they said they never saw this error before and suggested to check settings on our domain controllers. They also had me create a new realm and new auth. server, and it got the same error.
I have verified that the AD server settings are correct.
I tried specifying the Kerberos realm name on the auth. servers page instead of having it use LDAP to get Kerberos realm name. The Test Configuration was fine. But I then received this error in the Event Log: "realm ######## failed: Wrong realm."
Has anyone seen this error before? Any suggestions? Is this a bug with the new OS version?
I'm seeing the same problem on our SA-2000 after upgrading to 6.2r1, didn't see it before.
Cannot determine realm for AD server 5
Cannot determine realm for AD server 6
Uptill now, everything seems to work (except SSO Form Post, but that's a different problem )
I'm also running into this problem since upgrading to 6.2R1 (build 13255) from 6.0R3.1 (build 12507)
I have an open case with TAC to get their input.
This is in addition to an issue surfacing after the upgrade where I can't get a user's domain to not display in the UI greeting even if I disable it, which used to work before.
We have the same problem and have tried rolling back to 6.0 but this failed due to not being able to import the user or configuration files.
We also cannot add new users to existing roles or create new role mappings.
Raised a JTAC, but still waiting for some action.
I think 6.2R1 has broken it!
But normally rollback should run as (afair) the old system is moved to a spare partition for roleback purposes...
Anyway did you configure anything special with this AD realm? We got on, with just AD user/password auth for accessing a sharepoint portal through the IVE. We did not have any problems or such log messages after upgrading to 6.2R1.
We upgrade from 6.0R3 (build 12359) to 6.2R1 (build 13255) and are now suddenly faced with the same problem.
Users cannot use Network connect anymore. They are no longer able to login to the SA700 portal page.
The logs read like:
Info ERR24615 2008-08-05 13:31:55 - ive - [127.0.0.1] System() - Cannot determine realm for AD server 4
Info ERR24615 2008-08-05 13:30:01 - ive - [22.214.171.124] NT4_DOMAIN\PXandon(Domain Users)[Users] - Cannot determine realm for AD server 4
Info ERR24615 2008-08-05 13:09:46 - ive - [126.96.36.199] NT4_DOMAIN\FTichels(Domain Users)[Users] - Cannot determine realm for AD server 4
Info ERR24615 2008-08-05 13:06:47 - ive - [188.8.131.52] NT4_DOMAIN\FTichels(Domain Users)[Users] - Cannot determine realm for AD server 4
Info AUT20920 2008-08-05 13:06:38 - ive - [184.108.40.206] System() - Connection from IP 220.127.116.11 not authenticated yet (URL=/dana-na/imgs/space.gif)
We have one Auth. Server for the NT4-Domain NT4_DOMAIN and one Auth. Server for the AD. The funny part is that the users use accounts from the NT4_DOMAIN and the error message says "Cannot detemin realm for AD server 4" wich leads me to the conclusion that it thinks it has to use the AD instead the Nt4 domain.
Might it be that users enter "NT4_DOMAIN\username" in the login window but specify the AD realm from the drop down "REALM"?
Hi. A brief follow up to my upper comment.
Today we saw that a user who is using the IVE had a constant and huge amount of traffic from the public 443 port of the ive to his office location. There was about 5 GB of traffic floating from the ive to the users machine within 7 hours.
On the IVE under Status->Active users there where a couple of users but no one from this location had a network connect ip assigned.
We delete the sessions but the traffic continued to flow from the ive to the end user.
The traffic stopped when we flushed the firewall state tables on the users location firewall (sessions died).
So it looks like there is a huge amount of traffic floating from the ive to the client over port 443 which make the ive unavailable to the rest of the users. Kind of the web server is blocked/under stress.
After resetting the fw tables on the remote location (and having no more the traffic on the ive) we were able to login at the ive again.
So the questions is: "What kind of traffic is floating from the ive to the enduser on port 443 (5 GB in 7 Hours)". There was no IPSec visible.
I also have noticed this error in the logs since upgrading to 6.2R1-1 (build 13527) some months ago, but did nothing about it as everything seem to be working as expected.
The only reason I decided to see if others had similar issue was because I was having trouble with a user who is using a Mac and Network Connect and was not able to connect to the VPN and was getting an error that his connection was being refused and I thought that this error may have been part of the issue - rebooting Mac resolves the issue
However, it is interesting this is apparently a common error based on the number of times this topic has been visited. One would of thought that Juniper may have provide a solution or some feeback.