Jump to content

AD based External Auth


This topic is 3745 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Hi All,

We have AD based External authentication working however I have a question about our mac clients and using shortnames vs longnames.

 

Some server details:

We're using server 2008 R2 based AD domain controller.

We're using FMServer 12 Advanced running on a separate Windows 7 Enterprise VM.

Our FMServer is a domain member.

We haven't configured LDAP (yet)

 

Test database has a external auth group titled "staff"

We have an AD Group in "Users" titled "staff"

 

Our clients details

Windows clients are running Windows 7 Enterprise and Filemaker Pro 12 client

Windows Clients are bound directly to the domain and are signed in using AD accounts

 

Mac clients are running mountain lion 10.8 and are using FM Pro 12 Client

Mac clients are bound to the AD domain only.

Mac clients are signing in using AD accounts

 

Ok so the Windows clients are achieving perfect SSO. When we open our test DB we're not even prompted with a login screen, instead we are taken straight to our database and the assigned permissions are perfect.

 

On the macs however success is somewhat limited. When we attempt to login, we are presented with a login prompt. If the user keys in their shortname  ("exampleuser") they can login sucessfully and they get the expented permissions. However If they try to use their full name (Example User) they are denied access and presented with the standard "account and password are not correct" dialog box.

 

We are in the process of migrating 100+ users from using internal auth to External auth and I'd rather not have to reconfigure 100+ client desktops. Our staff are used to keying in their full names. Why can't we log in using the full name on Mac clients bound to the AD?

 

thanks

Ian

 

Link to comment
Share on other sites

First off: configuring LDAP has nothing to do with authentication users, it's a common misconception.

 

As to the issue: if I recall correctly only OD (not AD) supports both long and short names.  User accounts in AD only have one "name", there is not short name or long name.  So I'm guessing that the AD accounts are set up as "exampleuser"?

In that case when you send "example user", there is no match in AD.

Link to comment
Share on other sites

Hi Wim...

 

Thanks for replying. I'm aware LDAP has nothing to do with authentication, I was merely pointing out we'd not configured it.

 

I guess the i should stop using the term "long name" and instead use the term "Full Name".

We are logging on using AD with "Full Name" for every other service on the network - such as computer logons, AFP, and SMB fileshares etc. In fact the only place we can't log on using the Full Name is FileMaker.

 

Taking into account that the Filemaker Pro client seems to find the "Full Name" and uses this as the "System Name". The client pre-populates the account field for us with this information. If we're forced to then over-key that with the short name every time, that leaves external auth and the client login behaviour at odds.

Have I really got to tell my mac end users they're to delete the "Full Name" from the login box and key in their short name, every time they wish to login?

 

First off: configuring LDAP has nothing to do with authentication users, it's a common misconception.

 

As to the issue: if I recall correctly only OD (not AD) supports both long and short names.  User accounts in AD only have one "name", there is not short name or long name.  So I'm guessing that the AD accounts are set up as "exampleuser"?

In that case when you send "example user", there is no match in AD.

Link to comment
Share on other sites

Taking into account that the Filemaker Pro client seems to find the "Full Name" and uses this as the "System Name". The client pre-populates the account field for us with this information.

Hi Ian,

The other services use different protocols so there is no clear comparison there but I understand your frustration as to why it would work differently.

FM does not "find" the full name, it was just set that way when FM was installed and you can change it by going into the FM preferences and changing the "user name". I'm sure that is stored in a plist somewhere so it can be automated. Or left blank for better security.

The fact that FMP has that value has no bearing on how it would authenticate against an AD; it does not reflect a matching AD account.

Link to comment
Share on other sites

It does appear that FileMaker is querying active directory to display the full name. If I log onto a computer I've not used before, with filemaker already installed it displays my full name in the user name section of the open database dialogue. Likewise if another user logs into my computer it displays their name.

...FM does not "find" the full name, it was just set that way when FM was installed and you can change it by going into the FM preferences and changing the "user name"....

Link to comment
Share on other sites

That's not FM querying the AD though, that's FM asking the OS for the current account name of the OS's session.  It's a fine distinction.  When you log into a file, the AD is queried, not the OS so that is a different workflow if you will.

Link to comment
Share on other sites

The approach that would work for you is similar to what one would do in a citrix / TS deployment: use an OS logon script that takes the proper account name and write it to the FM preferences in the registry (where FM reads the user name from).  That way the account name is properly filled in with minium annoyance to the user.

 

On Mac that user name is stored in a plist somewhere.

Link to comment
Share on other sites

This topic is 3745 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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