11 Replies Latest reply on Mar 30, 2017 1:19 PM by Peter Wagemans

    OD to AD: user accounts

    Peter Wagemans

      I am migrating users from a MacOS based Open Directory setup to a Windows 2012 Active Directory setup for external authentication.

      I stumble upon a problem with this. While Open Directory support long account names, the active directory authentication appears to use the pre-Windows 2000 (what?) account name, which is limited in length.

      This is a serious problem, as I have currently no abstraction between account names and names IRL.

      Open Directory authentication can be used with both the short and the long name of an account, and FileMaker plays nice by showing the account string used during the authentication when you query it later using Get ( AccountName ).

       

      Is this a bug? Or am I expecting to much here? Is there a way to have FileMaker Server accept the more modern user logon name?

        • 1. Re: OD to AD: user accounts
          wimdecorte

          Hi Peter,  I will follow up on this tomorrow.

          • 2. Re: OD to AD: user accounts
            wimdecorte

            Hi Peter,

             

            See this for guidance: User Naming Attributes (Windows)

             

            The AD allows for two login syntaxes: UPN and UNC.  UNC is old-style (aka sAMAccountName) with UPN becoming more the standard.  The UPN account name follows the internet standard for email addresses.

             

            ad account 2017-03-24_18-10-11.png

             

             

            If the expectation is that you can use the 'full name' for users to log into a machine then that won't work.

             

            Even with OD authentication the best practice has been to always use the short name, and ideally to keep the long and short name of the account the same because FMI's support for the two different account syntaxes in OD has varied over time, but the short name has always worked without any issues.

             

            Your AD should not force you to pre-2000 formats unless you need it to be set up like that.

            3 of 3 people found this helpful
            • 3. Re: OD to AD: user accounts
              Peter Wagemans

              Dag Wim,

               

              Thanks for this research. This is helpful information. I guess I'll have to cut my losses and make "Windows Account to Filemaker Account" conversion custom functions. In my experience, the AD auth only responded correctly when I also added a space the the pre-2000 account name, I have this customer again tomorrow, let me get back after verifying again.

              The UPN logon is even further away from the human friendly approach. Luckily we have a keychain on both platforms now.

               

              'Your AD should not force you to pre-2000 formats unless you need it to be set up like that.

              Somewhere in the domain policy, not? But then I wonder, wouldn't Windows keep me from creating logons with spaces then? Again, I might be a bit spoiled by MacOS, expecting this :-)

               

              It would be convenient if the FileMaker developer is not confronted with the technicalities of a logon. There is nothing you can do with an OS logon in a FileMaker database. Unless you have an up-to-date table of logons and user names. While this information is available in both directory systems. Get ( AccountFullName ) ?

              • 4. Re: OD to AD: user accounts
                IanJempson

                Hi Peter

                 

                a Get(AccountFullName) function would be wonderful! We've had similar issues and have opted for the approach of keeping a table to map between logons and user names. I won't bore you with the lengthy discussions we had about whether to live with displaying the windows short names in FileMaker but it was going to create inconsistencies in display and some bits of functionality.

                 

                cheers

                ian

                1 of 1 people found this helpful
                • 5. Re: OD to AD: user accounts
                  wimdecorte

                  Peter Wagemans wrote:

                   

                  It would be convenient if the FileMaker developer is not confronted with the technicalities of a logon. There is nothing you can do with an OS logon in a FileMaker database. Unless you have an up-to-date table of logons and user names. While this information is available in both directory systems. Get ( AccountFullName ) ?

                   

                  Not a bad idea!

                   

                  For other's benefit on what we talk about here.  Taking the account that I show in the screenshot above, the user can log into the FM database with one of three different syntaxes:

                   

                  johndoe

                  ad\johndoe

                  johndoe@ad.connectingdataoffice.com

                   

                  All 3 would be accepted by FM and the Get(AccountName) function would show exactly what the user typed in to log in.  So if you rely on the output of the Get(AccountName) to restrict records for instance then you would need to make sure you deal with all 3 possible syntaxes.

                   

                  It has been like this since External Authentication was introduced in FM7.

                  2 of 2 people found this helpful
                  • 6. Re: OD to AD: user accounts
                    Peter Wagemans

                    wimdecorte wrote:

                     

                    johndoe

                    ad\johndoe

                    johndoe@ad.connectingdataoffice.com

                     

                    OMG. You're right.

                     

                    Ian, we would even need multiple records for 1 user to get the user name with a custom function. I would not like to do this with multikeys, especially using SQL. I think that using windows logon strings in a FileMaker layout is unacceptable. And since you like the idea of that extra function, I think you do to.

                    • 7. Re: OD to AD: user accounts
                      Magnus Fransson

                      Hi,

                       

                      wimdecorte wrote:

                       

                      Peter Wagemans wrote:

                       

                      It would be convenient if the FileMaker developer is not confronted with the technicalities of a logon. There is nothing you can do with an OS logon in a FileMaker database. Unless you have an up-to-date table of logons and user names. While this information is available in both directory systems. Get ( AccountFullName ) ?

                       

                      Not a bad idea!

                      Not that I know. But perhaps a plugin like for example MBS could be of some assistance.

                       

                      With best regards Magnus Fransson.

                      1 of 1 people found this helpful
                      • 8. Re: OD to AD: user accounts
                        Peter Wagemans

                        Magnus, that is a great idea. I took the MBS LDAP Query example file, and changed a few things:

                        - the username has to include the domain ( domain\user )

                        - port 389 instead of 390

                        - I made an extra domain field and included that in the bind script step

                        - authmethod "simple"

                        - Base: OU=Users,OU=...,DC=...,DC=local

                        - scope remained "subtree"

                        - for the filter field I tried "sAMAccountName::=<logon>" where logon is the value returned by Get(AccountName), that I cleaned up a bit so only the "johndoe" part survived (see above).

                        This still gives me about 32 records, but I get it working and will turn it into a custom function that only uses the "displayName" attribute its value. This value is the correct First Name and Last Name of the person.

                         

                        It's super fast, even when still running as a script and creating all those records, so it will probably be perfect as a custom function.

                        • 9. Re: OD to AD: user accounts
                          Peter Wagemans

                          Regarding, the pre-2000 credentials: I checked again today.

                          Logging in from the Finder to a share on the Windows server required the same pre-2000 logon.

                          So I tried an UPN logon with a space ( the same account having a pre-2000 login without spaces ) in the following scenarios:

                          - OSX Sierra -> FileMaker -> Fail

                          - OSX Siera -> Finder - Fail

                          - Windows 7 -> Explorer -> Success

                          - Windows 10 -> Explorer -> Success

                          - Windows 10 -> FileMaker -> Success

                           

                          So it seems like the authentication mechanism offered to MacOS clients is inferior to the one offered to Windows clients. If you are on a Mac, you can only use the pre-2000 logon, and not the UPN logon.

                          • 10. Re: OD to AD: user accounts
                            wimdecorte

                            The idea of UPN is that would be mapped to the user's email address; I don't think the RFC for email addresses supports spaces in them.

                             

                            macwindows.com is full of stories of incompatibility between Macs and Windows AD, going back many many years.  It's been a nightmare for as long as I can remember, mostly because of changes on the Mac side...

                            • 11. Re: OD to AD: user accounts
                              Peter Wagemans

                              Finally, after creating the LDAP custom function, and trying to implement, I … dropped it and went for the table based solution, with a simple SQL query.

                              I had this dark brown feeling the solution was getting slightly over-engineered. The biggest problem was the Go WAN clients (sounds like a Chinese diner), and I felt that Go/iOS SDK/MBS->LDAP support was getting a bit too technical and prone to problems after implementation.

                              The SQL query in a custom function is simple and stupid. The only disadvantage is that things are not live, but that is not such a big deal.

                              The ACCOUNT/LOGON tables are replicating the 1-to-many AD account/logon combinations, but can also be used for internal FileMaker accounts, in which case there is just 1 portal entry for the logon entry. Another advantage.

                              There are actually 2 custom functions I used: one to map Get ( AccountName ) to the actual user name, and one to map the user name back to the (first) logon.

                              So far, it looks good, but FileMaker should really add this extra Get(AccountFullName) function, not having a one-to-one relation between the account name and the logon string used is really NOT a good thing.