Problem with AD SSO after a windows DC server or FMS restart

[bluearrow]

Hi,

I have a Windows 2003 server / XP workstation /Filemaker Server 10 network, single domain. All latest patches are regularly applied to servers, workstations and the FMS. FMS is intalled on a member server machine (no AD on that machine).

There are two DCs on the network (two servers containing AD and replicating to each other). The network works fine in all respects and all software is also working fine. However, client Filemaker Pro 10 machines fail Single Sign On under the following conditions:

- Upon restarting one of the DC servers (which does not make any sense, as FMS could use the other to reach AD; in fact, users can restart their machine and logon to the network without one of the DC servers, using the other to authenticate). Users who are logged on to the domain and to FM (Filemaker database is open) when this happens, do not loose their connection to the database. They can work as usual. The problem is for users who do not have FM database open, or when the user closes the database and tries to reopen it. Filemaker opens, but authentication fails.

- Upon restarting the FMS machine without restarting the DCs (sometimes FM Single Sign On works after waiting several minutes - more than 15 minutes)

Users are logged on to their machine as Users, not as Administrators. They have no problems to log to the domain, under any circumstances. We have tried with new Windows 7 workstations and the problem with Filemaker SSO is the same under the above conditions.

This problem did not happen using FMS 9, on the same machines, same users, same AD FM groups, same database and identical SSO mechanism and opener file, on the same network. It seems to be an issue of FMS 10 (it happened with FMS 10 v1 and it also happens with the latest patch applied).

I have seen some post with similar problems. Any ideas on how to solve it? It is really annoying to have to tell users to wait 20 minutes to use the database, or have to restart server several times because we are not sure what is going on.

Thanks in advance

Edited March 3, 2010 by Guest

[Wim Decorte]

Most bizarre. I haven't heard of any other similar issues.

Are you getting a lot of warnings 661 in your applicatin event log on the FMS box?

What does the security event log have to say about it? There should be entries for each failed SSO log in and they should give you some clues.

The successful workstation login may be a red herring because Windows will use cached credentials if the AD can not be reached in a timely fashion.

I would suggest running for a few days with only one AD server active. If that solves the issue then I would concentrate on the AD replication process.

[bluearrow]

Most bizarre. I haven't heard of any other similar issues.

Thank you Wim. I am also surprised, as we have previously used and installed Server 5, 6, 7, 8, and 9 on the same network without any errors like this (at least, not that we have seen them or users have complained about it).

Are you getting a lot of warnings 661 in your applicatin event log on the FMS box?

Yes. And the description states: "Client "Whateverusername" authentication failed on database "Databasename" using "Admin [fmapp]".

What does the security event log have to say about it? There should be entries for each failed SSO log in and they should give you some clues.

Yess. Those entries exist and they correspond to "Failure audit" under Categories "Account Logon" and Account Logon".

For Log/Logoff the message is:

"Logon Failure:

Reason: Unknown user name or bad password

User Name: Admin

Domain: SERVER9

Logon Type: 3

Logon Process: Advapi

Authentication Package: Negotiate

Workstation Name: SERVER9

Caller User Name: SERVER9$

Caller Domain: DOMAIN1

Caller Logon ID: (0x0,0x3E7)

Caller Process ID: 1308

Transited Services: -

Source Network Address: -

Source Port: -

and for Account Logon:

Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0

Logon account: Admin

Source Workstation: SERVER9

Error Code: 0xC0000064

The server where FMS is located is a member server named SERVER9. The domain name is DOMAIN1. I am not sure why it is using the Admin account for all authentication, neither why it calls SERVER9 a Domain (it is not, neither it has AD; it is part of Domain1, and the same goes for all clients).

The successful workstation login may be a red herring because Windows will use cached credentials if the AD can not be reached in a timely fashion.

Yes. I have seen this and it makes it difficult to test if FMS and clients communicate with only one DC server. Also, I have noticed that there is a delay when users start Windows and when user may start the Filemaker database. This is normal under windows.

I would suggest running for a few days with only one AD server active. If that solves the issue then I would concentrate on the AD replication process.

This is not easy, as those DC serves also run other tasks that cannot be stopped for longer than 30 minutes. However, replication among DC servers is fine, and user accounts have been up and stable for years. The problem is not related to account creation or password change (we do change them twice a year, but the issue was present before and is present after this changes).

Any ideas

Thanks

[Steven H. Blackwell]

Check to be sure there are no auto log on credentials in any hosted files, whether the accounts are active or not. This includes the original "Admin" account with a blank password.

Steven

[bluearrow]

Check to be sure there are no auto log on credentials in any hosted files, whether the accounts are active or not. This includes the original "Admin" account with a blank password.

Steven

Thanks Steve. Checked. The hosted files were fine, no auto log on credentials. However, the opener file did have the admin account as log on account. This explains the errors accessing the hosted file. Now I do not see any errors on the server log files. Could this be related to the connectivity problems when restarting DC servers? I do not see the relationship among them.

Regards

Roberto

[Wim Decorte]

Yes. I have seen this and it makes it difficult to test if FMS and clients communicate with only one DC server. Also, I have noticed that there is a delay when users start Windows and when user may start the Filemaker database. This is normal under windows.

When authentication fails for FMS users: try to log into the FMS machine itself with one of the failing domain accounts and see if you get any errors.

[Tumbleweed]

I was wondering if this issue has been resolved or not? We have a similar problem with SSO on our FMS 10 server (Windows 2003 / single domain / 3 AD controllers) -- everything will be working fine for several weeks and then, suddenly, no new users can log in. Those users already logged in and using their databases can continue to work, but no one else can attach to the server until it is re-booted. We are currently using FMP 8 on XP-SP3 for our clients, but the same problem occurs using FMP 10 as well.

Symptomatically, the user selects "open remote file" and selects the server -- normally, a list of available databases appears -- however, the user never receives the list nor receives any errors. No evidence of a connection attempt is logged for either the Windows server or the FMS. Due to the user demand and the inability to force this error to occur, we have been unable to proceed with any detailed troubleshooting and fixes (other than re-booting the server).

Any additional information or thoughts on this would be appreciated.

Thanks in advance,

Jim

[Steven H. Blackwell]

There were some issues IIRC with FMP 8 and SSO. Are you using the 8.0v3 updater? And are you using Server 10.0v2?

Steven

[Tumbleweed]

There were some issues IIRC with FMP 8 and SSO. Are you using the 8.0v3 updater? And are you using Server 10.0v2?

Steven

If I understand the numbering scheme, we're using 10.0v2 (10.0.2.206) on the server and 8.0v2 on the clients; however, I neglected to mention that we have some Macs using AdmitMac and it appears that they are using 8.0v3.

Up until last fall, we were running FMS 8 with no problems until we added SP3 to XP. At that point, the upgraded users would be prompted for credentials (no SSO) and, if they waited two minutes or longer, would be able to log in. If they tried sooner than that, they would have to wait another two minutes before their login would work. At the end of December, we upgraded FMS to 10.0v2 with the recommended patch for this problem. Since then, everything's been working as expected with the exception of the logins freezing up -- six times since the beginning of the year.

Jim

[Steven H. Blackwell]

Try running those 8.0v2 clients to 8.0v3. Or better still, get everyone on at least FileMaker Pro 10.

Steven

[Tumbleweed]

Try running those 8.0v2 clients to 8.0v3. Or better still, get everyone on at least FileMaker Pro 10.

Steven

Moving everyone to 8.0v3 isn't a problem, so I think we'll do that next week. Moving everyone to FMP 10 isn't as straight-forward for a number of non-technical reasons (i.e., political).

I appreciate the input, Steven. Thanks

Jim

[Steven H. Blackwell]

Well as a practical matter, acquiring FileMaker Pro 10 won't be easy unless someone has it in stock. Since the current shipping version is 11, that's the version you're most likely going to need to acquire.

Steven