Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About kailou

  • Rank

Recent Profile Visitors

923 profile views
  1. Yeah, local groups with OD/AD/OpenLDAP accounts works great. Never had an issue until 13.0.2. I'm still trying to resolve this, though I've reverted to 13.0.1 and tabled my troubleshooting for the moment. "- on Windows, when the machine is a member of the domain, local accounts and groups will be ignored" Nah, I've got a mix of AD users and groups added to local groups, then its the local groups that are used for EA - FMS on Win machine. Don't know about local users within those local groups, though I can't see why those wouldn't work as well. RE: FMS and OD-only. I believe this is moot, IMO. As long as the relevant LDAP schema is in place and mapped it really shouldn't matter the source (OD/AD/OpenLDAP), FMS doesn't know the difference. This still may be my issue, though, if something changed in FMS 13.0.2 in the mapping - i.e., FMS is looking for the response in a different field than previously. Hopefully I'll have some time to do more troubleshooting soon.
  2. OpenLDAP as mentioned originally, not Apple's OD. Its an openldap directory on Linux servers on our campus network. I changed to OD because that was the way you seemed to be referring to the openldap directory in shorthand. I'm sorry if that was confusing. As mentioned above, I am not running Open Directory on any of my Apple machines. I tried running Open Directory and it had issues in a 'golden triangle' sort of environment on our network. How did I establish that things changed? First off, openldap auth worked under 13.0.1 and then fails under 13.0.2, with no other elements in the equation. So, that alone tells us something changed in the way 13.0.2 requests or interprets auth info. If nothing at all has changed on the system, then its more than logical to infer that it is a change in FMS 13.0.2. Next, I can now see it in the system debug logs. I've generated logs for the authentication process under 13.0.1 and then under 13.0.2 and I'm in the process of comparing them. 13.0.1 binds to ldap using GSSAPI, 13.0.2 out-of-the-box does a simple bind. I've now resolved that portion of it by introducing a PAM config for the fmserver_helperd. Now, when my FM openldap users attempt to login I can see in the logs that the auth process will sucessfully bind and authenticate to openldap under 13.0.2 just as it did under 13.0.1: Module: ldap - successful GSSAPI authentication for authzid - 'dn:uid=myopenldapuser,cn=accounts,dc=stanford,dc=edu' authcid - 'myopenldapuser' Module: ldap - Audit - success - Verify password for record type Users 'myopenldapuser' node '/LDAPv3/ldap.tld' BUT even though the LDAP portion now appears to complete successfully, openldap users in FMS still cannot login to FM. There is nothing further in the system logs; the only other log piece I get anywhere is the 661 error in the FMS Event.log.
  3. eh, not so quick, that was only part of the equation. Got the GSSAPI thing resolved, but still not authenticating. Ldap appears to be responding correctly, but FMS appears still not to be getting the info it needs…. *sigh*
  4. Ha! OK, I now know why its failing, but I don't have the fix just yet. My open directory logs weren't quite as verbose as I thought they were. I set that to debug level and suddenly got a whole lot more information Turns out that 13.0.2 has changed the way it hands off its authentication request to the OS, or in how it identifies itself to the OS, and as a result it attempts only a 'simple bind' to openldap with basic authentication; I need it to do GSSAPI. 13.0.1 actually properly followed the correct OS auth chain and would make the needed GSSAPI bind. I just now need to figure out how/where to make the needed modification - either within the FileMaker config someplace, or maybe its within pam.d as I had suspected earlier. If anyone has further insight I'd be grateful!
  5. Yes, FMS is bound (anonymous) to the OD. I don't have access to modify the OD, thus the local groups. I'm in a campus environment and the OD is hosted at the university level. Very convenient for many local uses. Yes, in general the OS behaves just as you mention - it checks available auth methods and returns the necessary info to authenticate. Ldap search does, in fact, return the local (non-OD) groups that OD users are a member of. All the users for my FileMaker databases are OD users, none of them are local OS users. Yep, the whole 'golden triangle' config is tricky, but I've had it working on OD and AD environments since v9. You may be on the right track in that the OS just isn't returning the auth data the way FMS expects. This may be the change in 13.0.2; 13.0.2 may be querying the OS differently from its predecessors. I'm surprised that I would not see any errors at all in the system logs.
  6. OpenLDAP users in local groups. 'Local' meaning the group is a system level posix group, not Open Directory. Open Directory is not running on the FMS machine. Users are all kept in an openldap directory elsewhere on the network. I add my users from openldap into the local groups on the FMS server machine. I then add the appropriate group to my FM databases for EA. The only time I've used a local posix user in a local posix group was as a troubleshooting measure to see if EA broke completely or if it broke only for the openldap users. Only the openldap users fail EA under 13.0.2. This is really similar to issues I had getting openldap to work with some other services (login,ssh,wiki etc) on the mini. The fix in those cases had to do with modifying the PAM config. So, it is certainly possible that has something to do with my 13.0.2 woes. Perhaps something in the auth handshake changed between v13.0.1 and v13.0.2. Nothing has changed with my PAM config for almost a year. Perhaps 13.0.2 needs some additional, specific tweaks in the PAM config that 13.0.1 did not need. Again, no log information what-so-ever, the EA fail is silent.
  7. Thanks, Wim. We can absorb small windows of downtime to test further if I had some additional things to try. I've spent 2 full days already trying to troubleshoot 13.0.2 in various ways before reverting to 13.0.1. If you have some ideas of things to poke at, I'm all ears. One thing that would be helpful would be some way to get FMS to generate verbose debug logs that would show all the steps it is taking in the EA process - I see no way to tell FMS to do this, so the FMS logs are currently not helpful. My system level logs are already verbose and they show nothing. So, I've been troubleshooting in the blind so far.
  8. Hey, don't knock the 'friendly guy'! ;-P No, have not escalated the issue. The friendly guy suggested the same, but that would be at a high rate for that support call and I'm too cheap for that call just yet. I'm not yet convinced that I've exhausted the existing user group knowledge base on the subject. I'm really hoping someone out there has come across something similar and can offer that one little nugget that would nudge me in the right direction.
  9. Issue: Update from FMS v13.0.1.224 to breaks external authentication of openldap users in local groups on OSX Server 10.8.5 I should note upfront that my FMS is currently working again only because I've reverted to the previous version - 13.0.1. I was unable to resolve the problem with 13.0.2. I'm tossing this out to the community to see if anyone else has seen this issue and if they've found a fix. My Environment: OSX Server 10.8.5 running on a mini. Current Installed Version FMS: OSX is bound to an openldap server on our network. This has been happily providing authentication for several services on the mini, including FileMaker Server since v11, and most recently with v13.0.1.224. Users from the openldap directory are added to local groups on the mini. The local groups are added to various FM databases for external authentication. No problem, been working just fine ... until the v13.0.2.295 update. This update breaks external authentication for the openldap users in the local groups. I have isolated the problem to know that it is definitely something with the 13.0.2 update and not anything else on the system, I'm just not sure which new FMS component is the culprit. Openldap users can still happily login to the server and other services hosted on the server, only FMS is effected. Throughout this process there have been no errors what-so-ever thrown to any system logs. I do see 661 warnings in the FMS Event.log, but I believe these to be red herrings. All databases have been double checked that fmapp is set for the local groups in question; authentication order has also been double checked. None of these were changed, anyway, from when it worked with 13.0.1. I have no 'opener scripts', never have. What I've tried: - Upgrade was first done with the updater. I did this twice, no joy. - Uninstalled FMS completely and installed full version of from scratch. No joy. - Created a new local user on the server and added that user to one of the local groups used by my FM databases. This user has no problem authenticating and accessing the databases. Openldap users in the same local group fail under v13.0.2 - I've compared files between the installations of v13.0.1 and v13.0.2 and so far have not found anything useful. Many of these files are binary, though, so I can't really see the what they are doing internally. - Spoke with FileMaker help line. Friendly, but no solutions and no similar reports in their knowledge base. Anyone else see this? Thoughts? Solutions? Cheers, Keith
  10. Like many I have also been struggling with this. I spent a day on it and finally have FMS working AND OSX Server (10.8.x) web services (including wikis). I just got it working so there may be issues to still work out. What I did is a twist on Goetch's solution. DISCLAIMER: I'm providing this info purely as a case study; I would not recommend doing this in a production environment; if you choose to try this you do so entirely at your own risk, I am not responsible in any way. I'm hoping others will be willing to try this and return here with their findings. I'm using named virtual hosts as opposed to multiple static addresses. You will have to start off by making 2 new aliases in your DNS that will allow your OSX Server to respond to more than one hostname. for the sake of this write up I will call my hostnames 'osx-www', 'fmwebd' and 'fmsadmin'. osx-www is whatever existing hostname your server currently listens on, the other 2 are the new ones. - FWIW, FMS does not actually install its own instance of apache. It uses the builtin OSX apache. What FMS does do is use its own set of conf files when starting up apache - As several have pointed out, in theory you could have FMS be the web server and move any of your own OSX web services into the FMS conf files OR vice-versa. To me it seemed more appropriate to move FMS stuff into the OSX conf files, that way I could more easily preserve OSX server functionality, including wikis etc. Brief summary of activities: - Turn off OSX Server web stuff, as indicated, and install and configure FMS - Once FMS is configured, turn off webdirect. make sure no httpd is running. - Configure new FMS apache conf files for webd and fmsadminconsole - Modify (slightly) your OSX Server httpd conf. - In OSX Server app restart your webservices. I created 4 new apache conf files for FMS. I placed these in /Library/Server/Web/Config/apache2/FileMaker. 1) vhost.conf so httpd listens also on fmsadminconsole port. It has only these 2 lines: Listen *:16000 NameVirtualHost *:16000 2) fmwebd_80.conf for webd port *:80 3) fmwebd_443.conf for webd port *:443 4) fmsadmin_16000.conf for fmsadminconsole port *:1600 ^^ I've pasted cleansed versions of these files at bottom of post. For 2,3 & 4 I started of by first using the OSX Server.app to create 3 new virtual hosts using the ports and associated virtual hostname. This created the base config files in /Library/Server/Web/Config/apache2/sites. Then I turned off webservices in the OSX Server.app. I *moved* the new conf files out of the 'sites' directory and into my 'FileMaker' directory. You have to move these out of the sites directory otherwise the OSX Server.app will step on them. You will need to get some information out of the FMS apache conf files. These are located in /Librbary/FileMaker Server/HTTPServer/conf and /Librbary/FileMaker Server/HTTPServer/conf/extra FMServer adminconsole: relevant FMS conf file: httpd-fmsadminserver.conf WebDirect: relevant FMS conf files: httpd.conf and httpd-ssl.conf FMS has a number of its own includes that you will need to add to the bottom of your fmwebd_80.conf and fmwebd_443.conf files. At the very bottom of the FMS httpd.conf you'll find a number of include conf files. You don't need all of them. I've attached my cleansed fmwebd_80.conf, fmwebd_443 and fmsadmin_16000.conf files at bottom; this will show you where I placed things. Once you've got your FMS conf files created then you will need to edit your OSX httpd.conf file (/Library/Server/Web/Config/apache2/http_server_app.conf). I did not need to modify any of my existing services, but I did need to load some additional modules and also add a line at the bottom to Include my new FMS conf files. This is the only line I added at the bottom of http_server_app.conf: - Include /Library/Server/Web/Config/apache2/FileMaker/*.conf - If you compare the FMS httpd.conf and the OSX httpd_server_app.conf you'll note that there about a dozen or more modules that FMS loads that your OSX Server may not be loading by default. Most of these, for me, were the proxy modules. Your OSX Server will need to load ALL the same proxy modules that the FMS httpd.conf loads, so uncomment them in httpd_server_app.conf if you need to. I also found that FMS was loading all the auth modules, so I uncommented those in OSX as well. That should be it for the httpd_server_app.conf. That's it. Restart webservices using Server.app. You should now be able to access all your existing OSX webstuff, including wikis, just as you did before. The fmsadmin console would be accessible at https://fmsadmin.domain.com:16000 FM WebDirect should be available at https://fmwebd.domain.com/fmi/webd The OSX Server app now controls all your webservices, including FMS. Turning off web services in OSX Server.app will also shutdown WebDirect and the fmsadminconsole. I look forward to hearing more from others on this topic. #----------------------------------------------------------------------------# fmsadmin_16000.conf <VirtualHost *:16000> ServerName fmsadmin.domain.com ServerAdmin example@email.com DocumentRoot "/Library/FileMaker Server/HTTPServer/htdocs/httpsRoot" # Setup the logs the way you'd like LogLevel warn CustomLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmsadminserver_access_log" 1209600 -420' "%h %l %u %t "%r" %>s %b" ErrorLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmsadminserver_error_log" 1209600 -420' TransferLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmsadminserver_transfer_log" 1209600 -420' <IfModule mod_ssl.c> # If you started creating this file by creating a basic vhost # using the Server.app then this section would contain your SSL info. # You could also copy/paste it out of any existing SSL using site.conf $ you may have </IfModule> # Everything from this point down came from the FMS # httpd_fmsadminserver.conf <FilesMatch ".(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory "/Library/FileMaker Server/HTTPServer/cgi-bin"> SSLOptions +StdEnvVars </Directory> BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 ProxyRequests off <Proxy *> Order deny,allow Allow from all </Proxy> <Location /> ProxyPass http://localhost:16001/ ProxyPassReverse http://localhost:16001/ </Location> </VirtualHost> #----------------------------------------------------------------------------# fmwebd_80.conf <VirtualHost *:80> ServerName fmwebd.domain.com ServerAdmin example@email.com DocumentRoot "/Library/FileMaker Server/HTTPServer/htdocs" # Setup the logs the way you'd like LogLevel warn CustomLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmweb_access_log" 1209600 -420' "%h %l %u %t "%r" %>s %b" ErrorLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmweb_error_log" 1209600 -420' TransferLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmweb_transfer_log" 1209600 -420' <IfModule mod_ssl.c> SSLEngine Off SSLCipherSuite "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM" SSLProtocol -ALL +SSLv3 +TLSv1 SSLProxyEngine On SSLProxyProtocol -ALL +SSLv3 +TLSv1 </IfModule> # Everything below came from the FMS httpd.conf # I actually don't think any of this is really needed, especially since # I'm using SSL <FilesMatch "^.([Hh][Tt]|[Dd][ss]_[ss])"> Order allow,deny Deny from all Satisfy All </FilesMatch> # # Apple specific filesystem protection. # <Files "rsrc"> Order allow,deny Deny from all Satisfy All </Files> <DirectoryMatch ".*..namedfork"> Order allow,deny Deny from all Satisfy All </DirectoryMatch> ScriptAlias /cgi-bin/ "/Library/FileMaker Server/HTTPServer/cgi-bin/" <IfModule cgid_module> # # ScriptSock: On threaded servers, designate the path to the UNIX # socket used to communicate with the CGI daemon of mod_cgid. # Scriptsock log/cgisock </IfModule> </VirtualHost> #----------------------------------------------------------------------------# fmwebd_443.conf <VirtualHost *:443> ServerName fmwebd.domain.com ServerAdmin example@email.com DocumentRoot "/Library/FileMaker Server/HTTPServer/htdocs/httpsRoot" # Setup the logs the way you'd like LogLevel warn CustomLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmweb_access_log" 1209600 -420' "%h %l %u %t "%r" %>s %b" ErrorLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmweb_error_log" 1209600 -420' TransferLog '|/usr/sbin/rotatelogs "/var/log/apache2/fmweb_transfer_log" 1209600 -420' <IfModule mod_ssl.c> # If you started creating this file by creating a basic vhost # using the Server.app then this section would contain your SSL info. # You could also copy/paste it out of any existing SSL site.conf $ you may have. Same as the fmsadmin.conf </IfModule> #----- FMS from httpd-ssl.conf -----# <FilesMatch ".(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory "/Library/FileMaker Server/HTTPServer/cgi-bin"> SSLOptions +StdEnvVars </Directory> BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0 # # These includes are from the bottom of the FMS httpd.conf # # Fancy directory listings Include '/Library/FileMaker Server/HTTPServer/conf/extra/httpd-autoindex.conf' # Reverse Proxy configuration Include '/Library/FileMaker Server/HTTPServer/conf/extra/httpd-proxy.conf' # Rewrite settings Include '/Library/FileMaker Server/HTTPServer/conf/extra/httpd-rewrite.conf' Include '/Library/FileMaker Server/Admin/admin-helper/WEB-INF/conf/fmi-test.conf' Include '/Library/FileMaker Server/Admin/admin-helper/WEB-INF/conf/mod_proxy.conf' Include '/Library/FileMaker Server/Web Publishing/publishing-engine/php/mountain lion/httpd.conf.php' #Include '/Library/FileMaker Server/HTTPServer/conf/extra/httpd-rewrite-fmiwebd.conf' </VirtualHost>
  • Create New...

Important Information

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