The problem last May was different, it was about forgetting to check the Client Authentication to allow "FileMaker and External Server Accounts". Unfortuantely, I got a lot of advice from people who have only set up authentication on the same machine and it wasn't really helpful for my situation and I am in a similar situation again. The situation from back then is working just fine now.
This is a different situation. I am able to log on using the local machines authentications of User ID's in the Operating System assigned to a group that FileMaker authenticates to. I am not able to use an Directory Service from another server for authentication (e.g., configuring Directory Service and pointing to the external machines IP). This is true even though after configuring the Directory Service, I press the Test button and it says successful. I have done this with other machines successfully, but it is not an area where I am Windows System Administrator and fully know what is going on. The Windows Admin in this case has asked me what needs done such as checking ports (389???) or entry points, etc. That is what I need some guidance in. The company wants all authentication to happen on one directory service and they do not want a separate one on this FileMaker Server, which makes sense.
Is there anyone familiar with external (not the same server that FileMaker Server is on) authentication services configuration?
It is still the same issue/solution as in the previous thread. The LDAP setting in FMS Admin Console is not relevant. The company I work with has many FM Servers, all of which are set to use External accounts, and none of them have any of the LDAP stuff turned on.
This comes down the Windows Server that hosts the FM Server being properly configured and being a member of the same domain as the separate box that runs the Active Directory authentication service. I am not familar with specifics of Windows server configuration, unfortunately. The windows admin should be familiar with setting up Active Directory. Maybe Wim or someone else will chime in with some specifics.
I fully agree with what you are saying... but you are giving me advice to configure the directory services to the same server that FileMaker is on. I need it to authenticate to a different server that has the directory services. Last May when I did this, as soon as I turned on the "FileMaker and external server accounts" checkbox, it started authenticating to the external server.
I have not taken training in Windows Server administration or Active Directory, but I am being asked that by the Windows Admin. I wish I knew why the one last May started working when I clicked the checkbox to authenticate.
There are a couple of options I do not know much about. One is that LDAP, which is the open standard used by Active Directory and FileMaker, needs configured differently. The other is that this Windows Server needs to be bound to the Active Directory of the other Server, but I have no idea where to start if that is the case. I have gotten it to work with LDAP in the past, but it is not now. If you're familiar with binding a Server to another Server or what I have done wrong with the LDAP, I am open to suggestions. But I'm starting to think I need to take this discussion to a Windows Server Admin blog. I just find the FileMaker community easier to work with so I wanted to try here.
Doug (and Chocoholic), I'm going to go ask the Windows Admin to make sure this FM Server is properly configured and being a member of the same domain as the Active Directory server. That is a starting point and thank you. Pardon my frustration when this isn't working. I appreciate it.
No, not saying to configure any accounts on the Server box that hosts FM Server. This box must be configured in the Windows Server OS to look to another (separate) box for authentication information. Example below - might not be 100% correct due to my lack of specific Windows Server mgmt knowledge.
Windows Domain: XYZ
- A member of domain XYZ.
- Configured as the Active Directory Host for domain XYZ.
- Groups are setup in the Active Directory that is on this server.
- Group called "Group1" is added to the AD and members/users "TaylorS" and "DougD" are added to this group.
- Hosts FM Server
- Is a member of the the XYZ domain.
- Does NOT have any local usernames or groups setup in the Windows Server OS.
- FM Server config has the feature to authenticate against local and external accounts turned on.
- FM Server hosts a database called "Test" and in the Accounts of the dB, we have created one called "Group1" and linked to a FM priv set.
- The Windows PC is a member of the domain XYZ.
- User "TaylorS" is logged into the PC.
- User opens the dB "Test" hosted on ServerB.
- I think the FM app and FM Server talk and agree that External authentication is enabled.
- FM app looks in the security of the dB and sees that it has Group1 as an account.
- FM app asks the Windows OS to authenticate the currently logged in user "TaylorS".
- Windows OS asks the Active Directory Host (ServerA) to return a list of all groups that "TaylorS" is a member of.
- ServerA responds that TaylorS belongs to the group "Group1".
- Windows OS passes this info back to the FM app.
- FM app lets the user into the "Test" database because we have an account named "Group1" in the dB.
I think you need to put this back on the Windows Admin person and/or post to a Windows server forum.
Pretty good write-up, Doug.
The key is that the FMS box needs to be a member of the AD domain. To check that you need to verify it on both the FMS box under Server Properties (it should list that is part of the domain), and on the AD box itself, the FMS machine should be listed in the AD as a member.
taylorsharpe: the directory service setting on FMS really does NOT have anything to do with it. And to avoid confusion, make sure to use the right lingo. LDAP is not a directory service, it's a protocol. Referring to LDAP as a DS is like calling HTTP a web server. AD on Windows and OD on OSX are both directory services that "speak" the LDAP language.
Thanks for the assistance and all the comments. I guess my problem was not understanding LDAPs role. I still don't understand when I need to configure it or not, but I now know to make sure that the FileMaker Server Machine is in the same domain control for Active Directory Authentication.
I'm getting there slowly into something I never really set out to learn <groan>. It is amazing how being a FileMaker developer, I keep getting dragged by customers into solving network problems or server configurations and things I have said I don't do. Somehow we seem to solve most of the problems. I have a number of clients that think because I know one service on a server (FileMaker), I know about all the other ones <oh my>. But it does help to work at clients that have a real Windows Server Admin!
Again, thanks for all the assistance!
It is amazing how being a FileMaker developer, I keep getting dragged by customers into solving network problems or server configurations and things I have said I don't do.
Key point that I have been making the last few years at my devcon presentations: we're good developers, but are we good deployers?
Our responsibilty does not stop when we save our last script and send the files to the client. If you value your reputation you need to assist the client in the proper deployment, and take control when it is boding well for the health of your solution.
I guess my problem was not understanding LDAPs role. I still don't understand when I need to configure it or not,
Almost never. In the last 8 years or so since we've had that option I've only had one client that used it. The server configuration for LDAP goes hand-in-hand with the FM client "Open Remote" option for "Hosts Listed by LDAP"
If you choose that option and configure it exactly like you did for the server the FMS box will show up and show its files. That's a client config that you would have to repeat for each installed copy of FileMaker Pro...
So why? Because you may have FMS on a different subnet as your clients. That implies bigger neworks. And typically we'd solve that by providing a starter file. The deployment headache of making sure each FM client has the right settings is just too much. It's easier on Windows because these things are stored in the registry and you can set them through a Windows logon script.
If you want want to see it in actual use, check out www.vtc.com for my FMS tutorial on FMS8 or 10, I forget which one I demoed it for.