External Server Accounts Issue

[mmcconnell]

I am perplexed by this situation:

FIleMaker Server 11.0.3.309 on XServe running 10.6.8.

XServe is bound to Active Directory and Open Directory.

Hosting 1 database.

Database Server configuration is set to FileMaker and external server accounts under Client Authentication.

All groups in OD match what is in FileMaker

The Issue:

When a user attempts to authenticate to the database, he receives an error message that the account will not work. He is then presented with the authentication dialog box again. As long as the user does not modify any information, including retyping the password, clicking on OK allows the user to authenticate as expected. Changing anything in the authentication dialog results in failure until it is left alone.

Each time this happens, FileMaker Server sends an email warning 661 "authentication failed on database "DATABASE.fp7" using "USER NAME [fmapp]""

This happens every single time a user attempts to authenticate.

I have confirmed that all directory services on the XServe are correct.

I am at a complete loss as to what is happening here.

[Vaughan]

Which version of the client?

If on a Mac, I'll bet they have stored the password in their Keychain. It's now no longer valid so it throws up the message.

[Steven H. Blackwell]

I am perplexed by this situation:

FIleMaker Server 11.0.3.309 on XServe running 10.6.8.

XServe is bound to Active Directory and Open Directory.

Hosting 1 database.

Database Server configuration is set to FileMaker and external server accounts under Client Authentication.

All groups in OD match what is in FileMaker

The Issue:

When a user attempts to authenticate to the database, he receives an error message that the account will not work. He is then presented with the authentication dialog box again. As long as the user does not modify any information, including retyping the password, clicking on OK allows the user to authenticate as expected. Changing anything in the authentication dialog results in failure until it is left alone.

Each time this happens, FileMaker Server sends an email warning 661 "authentication failed on database "DATABASE.fp7" using "USER NAME [fmapp]""

This happens every single time a user attempts to authenticate.

I have confirmed that all directory services on the XServe are correct.

I am at a complete loss as to what is happening here.

Vaughan's suggestion--as usual--is a good one. Do check and clear the KeyChain for any errant FileMaker Pro passwords.

But there may be more going on here. And the 661 error is instructive.

First, be sure that the files do not have the option checked to open automatically with credentials, including blank ones.

Second, this is an interesting statement:

XServe is bound to Active Directory and Open Directory.

What have you done here? Where are the Groups stored? On the OD Domain Controller or on the AD Domain Controller? Or are they local to the FIleMAker Server machine? And to which domain are the workstations with FileMaker Pro bound?

When we have a bit more information here, maybe we can further diagnose and correct this problem.

Steven

[Wim Decorte]

XServe is bound to Active Directory and Open Directory.

I want to highlight Steven's question here.

Why this setup?

FMS can work with either OD or AD, not both at the same time. OSX uses a tree-like structure for it's directory services so it will walk down the tree in order until it finds a matching account. If your OD is ahead of the AD in your tree structure but the account you want to authenticate is in the AD then I'm guessing FMS will stop at the OD...

Not sure why it works after the message comes up though.

[mmcconnell]

I want to highlight Steven's question here.

Why this setup?

FMS can work with either OD or AD, not both at the same time. OSX uses a tree-like structure for it's directory services so it will walk down the tree in order until it finds a matching account. If your OD is ahead of the AD in your tree structure but the account you want to authenticate is in the AD then I'm guessing FMS will stop at the OD...

Not sure why it works after the message comes up though.

Clients are all Mac OSX 10.6.8. They are also bound to AD and OD in that order. FMP 11.0.3 and FileMaker GO iPad

There are no passwords stored in the client keychains.

Files do not open automatically with stored credentials.

FileMaker groups are made from AD accounts, stored in OD groups (i.e. fmpStaff is a group in OD that contains AD users Bob and Steve).

Why have I done this? My systems have been set this way for more than 5 years. Our department is all Mac with local server and XSAN storage. The company provides AD from another location. All servers and clients are bound to both AD (for authentication) and OD (management).

Up until now, there has not been an issue with this setup.

The only change that has happened in the last few days was a scheduled power outage for our building. Everything was shut down prior to the outage, and started up again once the power came back on line. As soon as users attempted to authenticate, I saw the previously mentioned behavior.

Is it possible that this is a time-out issue? At first authentication to FMP, the computer "beach-balls" for a long time before giving an error. At second authentication, The database comes up almost instantly.

[Wim Decorte]

When a user attempts to authenticate to the database, he receives an error message that the account will not work. He is then presented with the authentication dialog box again.

What does the event log on the server say? I would expect an error 661 or something similar on the first attempt. Also check the system event log and whatever OSX has as security event logs. There should be good clues there.

[Vaughan]

The only change that has happened in the last few days was a scheduled power outage for our building. Everything was shut down prior to the outage, and started up again once the power came back on line. As soon as users attempted to authenticate, I saw the previously mentioned behavior.

I'd suggest that the timing of the server re-starts was that services were not available in the required order. It may be possible that the server is bound to the OD first and the AD second, whereas previously it was the AD first.

My advice is to check how things are *actually* set up now, not what you believe them to be or what they were before the restarts.