johny_canuck Posted January 26, 2009 Posted January 26, 2009 (edited) 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 January 26, 2009 by Guest
Steven H. Blackwell Posted January 27, 2009 Posted January 27, 2009 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
johny_canuck Posted January 28, 2009 Author Posted January 28, 2009 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.
Steven H. Blackwell Posted January 28, 2009 Posted January 28, 2009 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
Singlequanta Posted January 29, 2009 Posted January 29, 2009 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
Wim Decorte Posted January 29, 2009 Posted January 29, 2009 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.
Steven H. Blackwell Posted January 29, 2009 Posted January 29, 2009 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
Singlequanta Posted January 29, 2009 Posted January 29, 2009 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? :
Singlequanta Posted January 29, 2009 Posted January 29, 2009 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"
johny_canuck Posted January 30, 2009 Author Posted January 30, 2009 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.
Singlequanta Posted January 30, 2009 Posted January 30, 2009 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)
Wim Decorte Posted January 30, 2009 Posted January 30, 2009 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.
Steven H. Blackwell Posted January 30, 2009 Posted January 30, 2009 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
Wim Decorte Posted January 30, 2009 Posted January 30, 2009 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.
Singlequanta Posted February 1, 2009 Posted February 1, 2009 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.
Recommended Posts
This topic is 5849 days old. Please don't post here. Open a new topic instead.
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 accountSign in
Already have an account? Sign in here.
Sign In Now