Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Singlequanta

  • Rank
  • Birthday 03/30/1972
  1. Can anyone advise how to install the web server connector for FM6 unlimited on Win 2K3? I've got a client who has an old FM6 solution / CDML whos server has just died, so need to install this on win2k3. I know its possible, but when running the installation i get an error that I must configure a virtual Scripts directory first. (which I have already done) Help?!
  2. SSO and TS

    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.
  3. SSO and TS

    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)
  4. SSO and TS

    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"
  5. SSO and TS

    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? :
  6. SSO and TS

    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
  7. I have discovered a new "feature" that has arrisen as a result of a recent update with Windows XP Service Pack 3. When using external authentication between a Windows XP Pro Client and FMS9A running on Windows Server 2003, traditionally when the client entered the servers details (I.e. open remote hosts, then clicked on the server name) immediately the client would be presented with a list of databases available to that client based on the clients credentials -- without having to authenticate. of Course, opening any of the databases would result as expected, the client is silently authenticated, resulting in a seemless operation. However (And i have confirmed this with multiple clean installs) After installing service pack three, SSO partially breaks. The initial authentication token request when clicking on the service hostname seems broken in that the user is presented with a username/password dialog to enter their credentials. upon doing this, the list of available databases is presented to the user... if the user selects any of those databases, no further authentication is required. I've passed this on to FileMaker Australia for their comments. Steve
  8. Sydney Australia

    724 P/L has been developing niche FileMaker solutions for the better part of 15 years. We have a solid track record of commendable performance and outstanding achievement with several high-profile clientèle. Located in the Sydney CBD, we are seeking one or two junior to intermediate FileMaker Developers to join our team. The successful candidate will report directly to the Managing Director and will work as part of a development collective. The working environment is 50% in office and 50% off-site. Travel and accommodation supplied when necessary. The successful candidate will either have some development experience with FileMaker OR appreciable experience with relational databases such as MYSQL/MSSQL/POSTGRES etc. Critical to the role is an understanding of relational database development. The right candidate will receive extensive training if necessary. As the role specifically requires the candidate be on-site at client location, only local applications with fluent English and excellent communications skills will be considered. Contractors need not apply. This is a full time position. Salary range will reflect experience.
  9. Users can't log in anymore

    Another thing to check as well; If kerberos is involved; ensure that your machines clocks are all synch'd. Skewed time will certainly cause big issues with authentication. S
  10. Single Sign On....

    Steven; For what its worth; I do not feel the problem is directly with FMI; as when running the daemon in debug mode on the XServe; it is clear that the very second an attempt is made to access a database from a windows XP client; that an authentication token is being parsed and passed through. I will continue to diagnose this scenario and provide you with whatever learning I achieve. Steve
  11. Single Sign On....

    Im sorry Steven; my confusion and thanks for clarifying the position of LDAP. What I was referring to was your post as follows: Quote: This is the expected behavior. Single Sign On, as distinguished from External Server Authentication, is supported only from Windows clients to Windows OS servers running FIleMaker Server. It is not supported at all on Macintosh, because there is no concept of SSO in the Macintosh world. Switch FIleMaker Server to a server running Windows Server 2003 Standard Edition SP 2, and you can have SSO from Windows clients. Steven ---- End Quote ---- So it would appear that; even though we have no macintosh clients at all; and that our only mac equipment is our XServe; that Single Sign On for PC users is not possible with respect to a database hosted on a Mac XServe bound to our domain. Sigle Sign On -- in spirit -- is the process of passing authentication tokens between Operating Systems and SSO savy applications (Those applications which will receive a trusted authentication token) Of course; my confusion stems from the fact that FileMaker as an Application; is SSO Savy. My reference to LDAP was wholistic only; refering to the fact that FileMaker supports facilities to list itself within an LDAP Directory as you have indicated. What I should have said is: That in this day and age; where applications are LDAP Savy; Support SSO; and are more and more seemlessly supported within mixed environments.. it is a odd that in once instance a FileMaker Client can accept and process SSO Tokens passed from AD to FileMaker Server on the Windows platform; but can not properly accept SSO Tokens when the same database is hosted on a Macintosh Server bound to an AD Domain. In your tech brief; you state: Single Sign On. Fourth, Server External Authentication supports Single Sign On for the Windows platform and an analogous behavior on Macintosh OS X. This is a commonly employed technique in IS/IT system and network management. The concept behind Single Sign On, sometimes called universal authentication log–on or single–source log–on, is the belief that it simplifi es user credential management activity by requiring the user to remember only one set of credentials to access digital assets and network based assets. While this belief is almost certainly a correct one, nevertheless it does transfer the security of the database to something outside of FileMaker Pro. Developers may wish therefore to learn more about network security and authentication generally. Strictly speaking Single Sign On for FileMaker Pro 8 is a Windows OS client to Windows OS server feature only. However, in Macintosh OS X the feature can be mimicked by storing the credential information in the Keychain. I am curious; when you say "Strictly Speaking // however in Macintosh OS X I am sure you are referring to the concept of a Mac Client "SSO Process" but that you are not referring to SSO Tokens passed via a MacXServe from an AD controller? Or do i misunderstand? Im also a little confused because in another post you say: QUOTE: 1. External Server Authentication is one thing; single sign on is another. 2. IWP clients can authenticate against the server; they cannot do SSO. 3. Windows FMP workstations clients can have true SSO; Macintosh OS X clients cannot. They must use the Keychain instead. 4. The server accounts can either be on the domain controller, or they can be local accounts on the FMS server box. 5. Cross platform FMP client authentication can be a bit tricky depending on the OS of the domain controller. it is probably easier to have the DC be Active Directory. The AD plugins that are part of OS X seem to change every time Apple revs the OS, so some tinkering is always required. ---- END QUOTE ---- Here you state that AD is preferable; but that the AD Plugins for OSX may need some tinkering... I agree with you that it is considered best practise to employ single architecture and OS configurations when deploying more complex solutions; i just feel dissapointed that as you have said, with the Apple OS, "some tinkering is always required" Perhaps the XServe is simply a poor technology choice for any organization where AD has been implemented. Again; should you discover some method to permit Single Sign On between Windows XP Professional Clients and a FileMaker Database hosted on an XServe which is bound to the same AD controller as the requesting XP Professional Client; I am sure that I am not the only one out there who would benefit from such knowledge. Cheers Steve
  12. Oh CRAP! steven I just read your post re Single Sign On and Mac OSX. I have to say -- no where in any FileMaker documentation is this mentioned; only on here - that will teach me for not coming here first! We've got a mixed environment as well. XP Professional users on an AD domain; connecting to FM on our terminal server. I've been trying to get single signon to work for a couple of days now; and of course my headaches surfaced when attempting to have the users access the databases hosted on our XServe. In this day and age with active directory and LDAP integration; these sorts of things should be a lot more seemless. Looks like we are going to have to migrate our DBs over to our 2003 server : Such a shame because the XServe performs so much faster.... If you ever figure out how to jiggle this to work, please let me know! Steve
  13. Sydney NSW Developers?

    Greetings folks; We're a progressive development firm in Sydney NSW, Australia. We're kinda overworked, and looking for another developer or two. You: Junior/intermediate/or Guru; we want to hear from you. The only non-negotiable is that you *must* be in Sydney or close by as you would be required physically onsite. Pay will reflect experience. Contact me with your CV: steve@okanagan.net Cheers!
  14. Hey Justakid; There is no mechanism directly in filemaker to execute a script after x minutes of idle time. That is to say, if you opened filemaker and then sat there waiting for it to execute a script, this can't be done. However; I do this very succesfully using TROI activator. www.troi.com have a look at their website. As for your other question about locking a record after a period of time; you could also use troi activator to execute a script after xx mins/hours/days and have it lock a record or a found set. Hope thats helpful. S
  15. We have a full time position available for a junior to intermediate FileMaker developer in Sydney Australia. [color:red]This role specifically requires the successful candidate to be onsite, in person, here in Sydney. Therefore, and with all do respect, offshore contracting firms will be ignored. This is a junior to intermediate roll. Ideally you will have 2 to 3 years experience in developing FileMaker solutions. Send your resume in PDF format only -- to info@fmdev.com.au

Important Information

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