Password protection using FMSA8 & OD

[JohnDCCIU]

IT Auditors from the State have descended upon us and are insisting that our FileMaker databases be setup to:

1) enforce a minimum password length, complexity, and age.

2) lock usernames after 5 incorrect login attempts

I don't see a way to do that using internal FM authentication, so I've experimented with External Authentication in OS X Server OD.

Everything seems to work, except that the FileMaker login doesn't enforce the OD password changes/expirations/etc. It seems to happily authenticate the first time, even though OD says that the password must be changed the first time.

Many of my FileMaker users have no access to anything but the FileMaker databases, so I need FileMaker to notify the users that their password has expired, enforce the OD length/complexity requirements, let them change the password, etc. Is any/all of this possible?

If there are holes in what FM with External Authentication can do, can anyone suggest a solution that would let me do what I need to do?

Thanks for any advice.

[Matthew F]

Couldn't you manage this within FMP itself? I'm thinking of table of User names with a timestamp that records the time of the last password change. A script would checks the time of their last password change when the user accesses the database. New passwords could be set with another script that prompts for a new password with a custom dialogue box and then checks the number of characters and complexity. If your criteria are met then this would be passed to the 'change password' script step.

[JohnDCCIU]

One of the critical things is avoiding dictionary attacks by disabling the account after X unsuccessful logins. Could that be part of the system?

I was actually trying to avoid creating a development project; all the advice that I've seen says that if you're looking for comprehensive authentication, then go External Authentication and let OD take care of it....except it seems for when the passwords need to be changed, which FileMaker doesn't seem to support.

The other problem is that FileMaker seems to ignore OD's admonition that the password needs to be changed; it still lets the user login. Tools like /usr/libexec/chkpasswd say "Sorry" in this state, but FileMaker ignores it and allows entry. This seems very bad to me....looks like FileMaker is NOT a good OD client, unless I'm missing something.

[Steven H. Blackwell]

Perhaps the problem here is with the OD setup. Because if a user fails autentication, FMS will not grant admission to the files. Be sure that you do not have any auto-entered credentials in the files.

More on the changing of passwords later.

Steven

[Steven H. Blackwell]

On the change poassword issue please see this link as well as this one for additional information.

Steven

[JohnDCCIU]

Perhaps the problem here is with the OD setup. Because if a user fails autentication, FMS will not grant admission to the files. Be sure that you do not have any auto-entered credentials in the files.

There are no auto-entered credentials in this file, and if I login with any other invalid username/password, it denies access.

This situation only occurs when the OD server replies "password change required", as shown in the OD server's PasswordService log:

Nov 26 2007 10:32:54 RSAVALIDATE: success.

Nov 26 2007 10:32:54 AUTH2: {0x4749dd14123222a90000000800000008, } password change required.

FileMaker immediately allows the login (presumably based on the "RSAVALIDATE: success"), but it takes no action on the requirement to change the password, which it should if it was being a proper OD client that integrates with External Authentication (as it claims to be).

By contrast, a call to the simple chkpasswd utility generates the same log entries in the PasswordService log, but the client properly denies the login (although it also doesn't notify that a password change is required, but what do you want from chkpasswd ;-).

$ /usr/libexec/chkpasswd

Checking password for .

Password:

Sorry

$

[JohnDCCIU]

On the change poassword issue please see this link as well as this one for additional information.

Thanks, I ran across that utility and that may be what I can use to allow users to change their passwords...but how will they know that they need to change them? All other OD clients tell the user that a password needs to be changed....except for FileMaker. It seems to me that it should parse the return from the OD/AD server and at least tell the user what's going on, if not provide the function to change the password via the FileMaker login dialog (same as a local password).

I can educate the users and do it this way, but it will be very support-heavy and generate a lot of calls, no doubt. This seems like a lack of functionality/laziness on the part of FMI.

I guess they count on most users in this kind of situation also having access to AFP/SMB shares and the OS takes care of notifying the user and making them change their OD/AD password, but that seems like a flawed assumption. Even if the users had access to both shares and FM databases, confusion would reign if they accessed the FM databases before hitting the shares.

[JohnDCCIU]

One of the critical things is avoiding dictionary attacks by disabling the account after X unsuccessful logins. Could that be part of the system?

I discussed this via email with the author of the very cool FileMaker utility called "Account Manager". It seems that there's no hook into the FileMaker login interface for developers, so there's no simple way that a FileMaker-based system can determine when an unsuccessful login has occurred. Thus it would seem currently impossible to have FileMaker disable an account or take any other action based on unsuccessful logins. So it seems that I'm stuck with External Authentication, as clunky and support-intensive as it will be.

I may have to hack something together to continually parse the OD PasswordService log, associate usernames with email addresses, and email the user when various messages come up. Ick.

It really seems like FMI hasn't thought this External Authentication thing through very well, at least not in the context of providing necessary notifications and the ability to change passwords to FileMaker users.

[Steven H. Blackwell]

I guess they count on most users in this kind of situation also having access to AFP/SMB shares and the OS takes care of notifying the user and making them change their OD/AD password, but that seems like a flawed assumption. Even if the users had access to both shares and FM databases, confusion would reign if they accessed the FM databases before hitting the shares.

I don't agree, but I will pass this along to them. Why aren't users being challenged when they log on to the network to change their outdated credentials?

Steven

[JohnDCCIU]

I don't agree, but I will pass this along to them. Why aren't users being challenged when they log on to the network to change their outdated credentials?

We have staff users all over the place: at home, at our sites both tiny and large, placed in our 12 far-flung school districts, all over the state, etc. Most don't "sign in" to our network or a central OD/AD controller: they just login to their computers with local accounts and use FileMaker, FirstClass, and MS Office.

We do have such a centralized system for our student laptop initiative (all OD with Mobile Accounts) for the purpose of central control, but none of them need/use FileMaker.

I guess FMI is assuming that kind of centralized system is taking care of things up front, and that probably is a majority of cases so it's probably a reasonable one.

I suppose that I could make a major change in the way that we do things and centralize all of our staff authentication for OS logins, but that's a huge job when we just want to be able to do FileMaker authentication via an external server and have it handle the password stuff.

In any case, thanks for all of your insight and advice on this; it's much appreciated and has given me quite a bit to think about.

[Steven H. Blackwell]

Depending on the number of Accounts and Groups (mostly Accounts) you could take the FMS server [color:red]out of the OD Domain and use local Accounts and groups via WorkGroup manager. That way it doesn't matter where the users are when they seek authentication.

Steven

[JohnDCCIU]

Depending on the number of Accounts and Groups (mostly Accounts) you could take the FMS server [color:red]out of the OD Domain and use local Accounts and groups via WorkGroup manager. That way it doesn't matter where the users are when they seek authentication.

I could do that if it made a difference...would FileMaker properly notify users of expired passwords that they need to be changed, and allow the users to change them, if it's all local accounts and groups on the machine?

I didn't think it would make any difference if the accounts were external to FileMaker itself, regardless of whether they were OD accounts or local OS X accounts....

[Steven H. Blackwell]

[color:red]FileMaker won't ever notify users of credentials lifecycle isues with external Accounts [color:red]precisely because they are external Accounts. The domain controller must handle that or WorkGroup Manager. When they are local Accounts on the server this isn't likely going to happen.

My suggestion to put the accounts on the local server was to allow you to address those users who never log onto the domain.

Given the tree search patterns in OS X, you may be able to have both types of Accounts, domain and local server.

Steven

[JohnDCCIU]

[color:red]FileMaker won't ever notify users of credentials lifecycle isues with external Accounts [color:red]precisely because they are external Accounts. The domain controller must handle that or WorkGroup Manager. When they are local Accounts on the server this isn't likely going to happen.

My suggestion to put the accounts on the local server was to allow you to address those users who never log onto the domain.

Given the tree search patterns in OS X, you may be able to have both types of Accounts, domain and local server.

From the point of view of these remote users, OD accounts really aren't any different from local server accounts: they will login using their credentials, but won't have any idea that their password has expired.

I see some logic in FMI's current assumption that all users authenticate first to the OD before trying to authenticate to FMS, but in at least some cases, that assumption is flawed. I'd like to see them make FMS into a fully functional client to the OD/AD server (which is of course what it is) that reports credentials issues to users and allows them to change their OD/AD passwords.

WGM and the DC don't handle user notifications and password changes: the clients handle that. The client can be the OS, of course, but FileMaker is also acting as a client, and it should have that same functionality IMO.

Anyway, I appreciate your help in nailing this down; this really helps in determining what my current options are.

[Steven H. Blackwell]

I see some logic in FMI's current assumption that all users authenticate first to the OD before trying to authenticate to FMS, but in at least some cases, that assumption is flawed. I'd like to see them make FMS into a fully functional client to the OD/AD server (which is of course what it is) that reports credentials issues to users and allows them to change their OD/AD passwords.

I'll look into this further and contact them regarding this particular scenario.

Steven