Active Directory SSL for encrypted connections through LDAP

[Juan David Gil]

I have an Active Directory for user authentication for our FMP users. 

I, however, must use unencrypted connection because otherwise it does not work.  I have tried and tested the same parameters on other solutions to authenticate against AD, and they work, but with FMS, it works only unencrypted.

I read the Manual, it says that I must use a certificate, but my domain is '.local' and I don't understand why it needs a supported certificate for this matter. I did install a certificate for FMP so in order to avoid the annoying web direct security statement.

All said, I have a Windows 2008 R2 level domain, with 3 servers to authenticate against.  A dedicated FMS windows 2008 r2 server that belongs to the domain.

What must I do?

[Wim Decorte]

The FMS SSL certificate is there only to encrypt the FM data-in-transit between the FMP clients and FMS.  It doesn't do anything for the communication between FMS and the AD, that is largely handled by the OS.

If you are referring to the LDAP / Directory Service section of the FMS admin console: note that it has nothing to do with authentication at all.

Can you describe a bit how you set up SSL to AD for your other solutions?

In FM, the only thing you need to do to make make AD authentication work are:

- FMS needs to be a member server of the domain (you have that already)

- FMS needs to be configured to allow "filemaker and external accounts" (nothing else, not that "directory service" section)

- the FM file needs to have external accounts (groups) set up

It sounds like you have all of that covered and that it works under certain circumstances?  I don't understand how you toggle SSL on and off for your AD though.

[FoggyMt]

Rather than start a new thread, I think I'll jump a ride on this one.  And forgive me.... I know next to nothing about LDAP.

I've got a functionality question, Wim. My client is hoping to store staff data (employee type, employee level, etc) in LDAP and have various FM databases reference, talk to that data. Is that even possible?

I'm talking beyond merely an account group....can FM reference and store to LDAP tables?

Edited March 17, 2016 by FoggyMt

[Juan David Gil]

Thanks Wim, I will answer accordingly

15 hours ago, Wim Decorte said:

If you are referring to the LDAP / Directory Service section of the FMS admin console: note that it has nothing to do with authentication at all.

I am referring to the authentication of user names against an Active Directory. You set up a server, and must give them FQDN a port and a type of encryption.

Quote

Can you describe a bit how you set up SSL to AD for your other solutions?

For instance, the mail server get all accounts with user names @domain.com and authenticate them internally against an AD domain server with @domain.local accounts using SSL with a self signed certificate from the server... but its encrypted! I use with them Port: 636 using LDAPS protocol.  And thats it.  

- FMS needs to be a member server of the domain (you have that already)

It is a member of the domain, but it has no role at all as a server for any of the Active Directory services.

Quote

- FMS needs to be configured to allow "filemaker and external accounts" (nothing else, not that "directory service" section)

- the FM file needs to have external accounts (groups) set u

Done!  Indeed it works!  But using non encrypted connection, thus, raising alarms in the DC.

Quote

It sounds like you have all of that covered and that it works under certain circumstances?  I don't understand how you toggle SSL on and off for your AD though

You activate it in the admin console, under the 'Database Server' --> 'Directory Service' --> 'Use Secure Sockets Layer'.  AD is listening on 686 for the SSL connection.

1 hour ago, FoggyMt said:

 

I'm talking beyond merely an account group....can FM reference and store to LDAP tables?

I too wish to know this.

[Wim Decorte]

8 hours ago, Juan David Gil said:

 

You activate it in the admin console, under the 'Database Server' --> 'Directory Service' --> 'Use Secure Sockets Layer'.  AD is listening on 686 for the SSL connection.

This is the part that I mentioned before: that "directory service" section of FMS has NOTHING to do with authenticating users.  It is only there to let people find info about the FMS in their directory service.  So whether you use this section or not, it does not make one bit of difference for the authentication of users.

8 hours ago, Juan David Gil said:

It is a member of the domain, but it has no role at all as a server for any of the Active Directory services.

FMS does not need to have any AD servcies role, it just needs to be joined to the domain (becoming a member server) so that it knows who to contact with the authentication request.

8 hours ago, Juan David Gil said:

Done!  Indeed it works!  But using non encrypted connection, thus, raising alarms in the DC.

Can you explain this one a bit more?  What setting do you have in AD that would make it raise these alarms?

9 hours ago, FoggyMt said:

Rather than start a new thread, I think I'll jump a ride on this one.  And forgive me.... I know next to nothing about LDAP.

I've got a functionality question, Wim. My client is hoping to store staff data (employee type, employee level, etc) in LDAP and have various FM databases reference, talk to that data. Is that even possible?

I'm talking beyond merely an account group....can FM reference and store to LDAP tables?

LDAP is a protocol (a language so to speak),  not a database.

You can certainly use the LDAP "language" to talk to any directory service and read data from it.  But the underlying data tables of things like an AD can not be referenced or treated like native FM tables.

So: yes, you can query say AD or OD or any other Directory Service through any of the supported protocols, of which LDAP is the biggest.  But AD for instance also supports ADSI, and has built-in PowerShell command-lets to do some of this stuff.

To write back to it: you may need the right privileges and that is probably not the kind of rights you want to give to all users...

 

 

[Juan David Gil]

Thanks again Wim.

4 hours ago, Wim Decorte said:

This is the part that I mentioned before: that "directory service" section of FMS has NOTHING to do with authenticating users.  It is only there to let people find info about the FMS in their directory service.  So whether you use this section or not, it does not make one bit of difference for the authentication of users.

Right.  You are right.  But notice that my problem is that when the FMS goes to check the AD, it does so without any encryption and in plain text.  Thats why I would like it to be secure.

The kind of alarms that it raises are the EventId: 2887 on the server administrator window.  It specifies that clients are being authenticated against the AD without any encryption.

[Wim Decorte]

Here's the thing though: FMS does NOT talk to the AD, FMS talks to the OS on the server it is on and it is that OS that talks to its AD.

So I wonder if the events go away if you remove the directory service config from the FMS admin console.

Does that event 2887 specifically list filemaker requests?

 

 

 

As an afterthought: do you have Mac clients where the OS has been bound to the AD?

[Juan David Gil]

2 hours ago, Wim Decorte said:

Here's the thing though: FMS does NOT talk to the AD, FMS talks to the OS on the server it is on and it is that OS that talks to its AD.

So I wonder if the events go away if you remove the directory service config from the FMS admin console.

Does that event 2887 specifically list filemaker requests?

 

 

 

As an afterthought: do you have Mac clients where the OS has been bound to the AD?

Are you sure?  This is a surprise to me! To be honest, I always thought that the server was the gateway between FMS clients and the AD.  I have to admit I don't know much about this.

Then, what does that check mark do on that 'Directory Service' do?.  I am sure the EventId started happening since I installed FMS and the server that flags that event is only authenticating FMS requests, but never realized that clients do not use FMS as a passthrough to the AD. So, If I understand, the clients read the data from the FMS and then they directly challenge the AD server?

To answer your question: I am working FMP on a Mac client bound to an AD.  

Following your valuable insight, I will see if only using Windows clients that are bound to the AD will also spawn the EventId on the server.

Thanks

Edited March 17, 2016 by Juan David Gil
Incomplete and some typos spread around the text.

[Wim Decorte]

4 minutes ago, Juan David Gil said:

never realized that clients do no use FMS as a passthrough to the AD.

That's not what I said though.  FMS *is* used as the passthrough to the AD.  But FMS does not talk to the AD directly, FMS asks the OS on its own server and waits for a response from the OS.  It's the OS that makes the request, hence the requirement that the FMS machine needs to be a member server of that domain.

6 minutes ago, Juan David Gil said:

Then, what does that check mark do on that 'Directory Service' do?

What check mark exactly?

Note that the "directory service" section of the FMS admin console has NOTHING to do with authentication of users, as mentioned a few times before.  It is meant to allow people to find filemaker servers in a big / heavily segmented network.

It can go hand in hand with similar settings in FileMaker Pro (client) (see screenshot)

 

7 minutes ago, Juan David Gil said:

To answer your question: I am working FMP on a Mac client bound an AD.  

Perhaps that is what is generating the errors on AD.  You do not need to bind the Mac client to the AD to make External Authentication work, it's enough that the FMS machine is a member server.

 

 

 

 

[Juan David Gil]

Hi Wim... I am latin, always say hi. 

The check mark is the one that says "Use Secure Sockets Layer (SSL)" on the picture.

10 minutes ago, Wim Decorte said:

What check mark exactly?

I know you have repeated here a few times, but I do understand, eventually.  Thanks for the patience.

Edited March 17, 2016 by Juan David Gil

[Steven H. Blackwell]

The tab you are displaying for LDAP registration has nothing to do with External Server Authentication for FIleMaker Pro files.  Its only purpose is to publish a list of the FIleMaker Servers on a network.  You'd probably be better of not using the LDAP item at all.

External Server Authentications requires Groups in the Accounts section of the file, identically named Groups on the server (either local server or Domain Controller), Accounts placed into those Groups, and the toggling a single switch in the Admin Console Security Tab as shown below.  If using Domain level Accounts, the Server must be a member of the Domain.

 

 

Steven H. Blackwell

 

[Wim Decorte]

As Steven said: narrow the issue down by removing two things from the equation:

- remove all settings from the Directory Service config in FMS, save the changes

- remove the AD binding for the Mac workstation; unless you absolutely need for anything beyond FM EA.  FM EA does not care if the workstation is bound to the domain, there is no SSO to be had anyway if there is a Mac involved.

Then see if you still get errors on your AD.  If you do then I would suggest you configure your AD controller to long all individual non-signed requests instead of the catch-all once-a-day event ID that you are getting now.