Jump to content
Sign in to follow this  
johny_canuck

SSO and TS

Recommended Posts

I have a TS server setup with vla FMP 9 and the files are running on FMSA 9. The TS OS is MS Server 2003 SP2 and FMS9 is running on an XP sp3.

I have the FMS settings set to "only display files that user is allowed to see" and when I try to connect to FMS I am being prompted to authenticate in order to display the files. Is there a way for FMP to use the users windows login to authenticate and display the appropriate files? When I click on the available file, it does use the user's Windows login credentials to authenticate and login to the solution. Is this the result of the bug reported by Steven (sticky post)? I'm hoping that this is only valid for user's workstation and not server.

An alternative would be to have an opener file on the user's desktop but I can't figure out a way to have the opening script use the user's Windows credentials to open the remote file.

Any help would greatly be appreciated.

Edited by Guest

Share this post


Link to post
Share on other sites

This is the cause of your problem:

and FMS9 is running on an XP sp3.

Service Pack 3 on XP broke part of External Server Authentication related to database visibility. In FileMaker Server 10 it works correctly.

You can fix your present situation using the 9 family of prodcuts by running FileMaker Server 9 on Windows Server 2003 SP 2, and by running the TS virtual sessions on Windows Server 2003 SP 2 with FileMaker Pro 9.0v3.

Steven

Share this post


Link to post
Share on other sites

I don't think that I'll purchase another license of Server 2003 just to solve this problem. The client will have to live with the authentication.

Has anyone tested Server 10 on XP sp3? Yes I know it isn't a supported environment but that doesn't mean that it won't run. MS has repeatedly delayed the end of life support for XP and probably will until Windows 7 is ready. There are still many issues with Vista and older hardware (mostly driver issues). Only one of my government clients is planning to migrate to Vista this year, all others are still deployed on XP.

Share this post


Link to post
Share on other sites

This problem does not exist with FileMaker Server 10 running on Windows Server 2003 SP 2 when users connect with Windows XP SP 3. FileMAker Server 10 does not run on Windows XP.

Steven

Share this post


Link to post
Share on other sites

Steven;

Do you know if external authentication in mixed environments is now working properly? As you may recall, with 9 this scenario would not work:

1. Server: OSX & FMServer 9

2. AD: Windows 2003 Active Directory

3. Server is bound to AD Domain

4. Client: XP

The SSO Tokens for the client, logged into the domain, are forwarded to the OSX Server for authentication, but the authentication fails

Im sure you and I have talked about this before; I was wondering if you are aware of any fixes to this scenario that will enable SSO of an XP client to an OSX Server bound to an AD Domain controller?

SG

Share this post


Link to post
Share on other sites

External authentication in your scenario will work, that is fully supported.

However SSO will never work and there is no solution for it. True SSO will only work in an all Windows environment starting with the users logging into their Windows machines with the domain account.

Let's not confuse SSO and EA. EA is all about where the accounts are stored and where the authentication is happening. SSO refers to the fact that users can get authenticated without retyping their credentials.

Share this post


Link to post
Share on other sites

Just switch to a Windows Server and you can have SSO. Macintosh users can emulate SSO with the KeyChain, but that raises its own set of issues.

Steven

Share this post


Link to post
Share on other sites

Ultimately that's what we did.

The reason I was asking, is because I've got this XServe that we purchased because FileMaker claimed the scenario would work - the machine is now just collecting dust.

Anyoneone wanna buy an Xserve?

:

Share this post


Link to post
Share on other sites

Previously EA didn't work in that scenario. I can live without SSO, but i can't live without EA.

We've reported it to FileMaker on several occasions, but to date (over a year and half now) haven't had a reply other than "we're looking into it"

Share this post


Link to post
Share on other sites

Hi Wim,

I just tried this setup this afternoon and I couldn't get the users to authenticate against the AD (regardless of SSO).

FMS 9 running on OSX 10.5.X bound to AD running on Server 2003 sp 2. FMP clients running XP sp 3. They get authenticated into the Terminal Services but the Filemaker client just won't authenticate.

I tried several settings in FMS to get things going but I must be missing something. When I click on the Test Directory Service Settings it says that it is working fine but users can't authenticate. I've triple checked their profiles and passwords.

If I move the files back to FMS running on a Windows box then the clients can authenticate (SSO doesn't work because FMS was on XP sp3).

Any help would be greatly appreciated.

Share this post


Link to post
Share on other sites

Hi J;

I don't think you're going to have any luck with this. I've spent many long hours trying to get this configuration to work with no success. To date, Im still waiting for FileMaker to reply to my support request on the matter (which was submitted April 2008)

Share this post


Link to post
Share on other sites

Strange that you got no better reply from FMI on this.

The scenario you describe has been tested by me and Steven explicitly as part of our testing for writing the EA tech briefs. So I know it works.

Having said that, mixing platforms certainly adds to the complexities. I've been on many client calls trying to get this to work in mixed environments. Usually it does but sometimes the exact version of the OSX machines involved, how DNS is set up on the network,... all variables that I've seen trip this up.

SSO is one of the most complex things in networking and it relies on a wide variety of technologies. Having multiple vendors with their own interpretation of those technologies and standards doesn't help.

But know it works.

Share this post


Link to post
Share on other sites

Macintosh Server likely not bound correctly to domain. Do NOT use the automatic search path. Use a specified path instead.

All that said, there are issues every time Apple revs the OS with its breaking the AD plug in configuration. This is particularly true of OS 10.5. Some of this may be due to encryption of passwords across the network. The MacWindows web site has a lot of information on cross platform authentication.

Steven

Share this post


Link to post
Share on other sites

Oy... you're confusing a few things.

The "Directory Service" tab in the FMS config has nothing to do with EA. That's just for "announcing" your FMS in the directory service. Like putting your phone number in the phone book. That has nothing to do with authenticating users.

I would suspect that the binding from the OSX machine to the AD is not working correctly. Try this:

- on the FMS machine, try to log into the machine with an AD account. If the binding is good that should work because OSX knows where to send the authentication request

Make very sure that no duplicate accounts exist on the OSX machine like they exist in the AD. If you have accounts with the same name on the OSX machine, FMS will stop there and not look at the AD.

Share this post


Link to post
Share on other sites

I haven't tried this again since last April/May but at that time it didn't work. Gave the exact configuration we had to FileMaker (Australia) who were able to replicate the failure. Have emailed them a few times since and no reply.

Might give it another go with recent OS patches etc and see if i can make it work.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.