So part of the application that I have been working on uses an external data source (SQL data), but our DBAs arenot keen on using SQL accounts to access data - they would we set up a service account on the AD which can be granted the appropriate access to the database.

So I have an ODBC connection, and under authentication, I have three options:

1. Prompt user for user name and password - Not an option

2. Specify user name and password (applies to all users) - this works with a SQL account

3. Use Windows Authentication (Single-Sign-on) - confused as to how this would ever be used?

Can someone please confirm if its possible to use an AD account instead of a SQL account for setting up SQL database access?

Thanks

Martin

#2 should work with the service account

 

#3: what's confusing about using Windows SSO?  If the client machine is Windows and part of an AD domain, this is the absolute easiest setup.

Thanks. We tried this with the test server, and had to re-install FM Server under the service account, but couldn't get it to work, so went back to using the SQL account.

For the live server, we set that up as the default local admin account, and again, using the SQL account seems to work.

Can anyone explain how the permissions work with this?

And re: SSO, asking for SPN is what is confusing - the admin guys who I have asked for the details aren't happy to provide it without understanding more of what is actually required.

Thanks for replying

Martin

Thanks. We tried this with the test server, and had to re-install FM Server under the service account, 

 

It's totally unrelated.  And it would affect any server-side schedules that would use OS-level scripts.  Changing the account from "local system" to an AD service account is not something to do on a whim.

Thanks.

 

I'm still none the wiser, so will stick with the SQL accounts (as they work).

 

Martin

Here's the help section on setting up SSO for ODBC data sources:

 

http://www.filemaker.com/help/13/fmp/en/html/odbc_ess.20.7.html

 

It lists all the steps you need to take.  If the admin guys don't want to cooperate then there is not much you can do.  But usually good IT folks jump at the opportunity to centralize security and accounts and using SSO squarely falls into that realm.