On Nov 9, 2018, at 7:34 AM, Robert ListMail wrote:
> I’ve inherited many 4D databases over the years and some have a custom
> password system and some use the built in 4D system or a hybrid approach. I
> know that 4D also allows authentication via Active Directory (single sign on)
> but I’ve not implemented that. So, I’m looking to enhance a few legacy
> systems and wanted to consider my authentication strategy... I’ll probably
> want to keep the users and groups in the data file so that the data would
> always be valid after structure changes and to store more data about each
> user. Also, what if users could register on the system and use the system to
> reset passwords and such just like a public web site, this would lighten the
> load for the admin... I know this was all the rage 20 years ago. So, have you
> rolled your own password system in 4D? What are the key benefits in your
> situation?
I have a table called [Users] that stores authorized users of the database. In
the past it was the sole authentication system. Didn’t use 4D’s password system
because it is structure based and installing new version of the structure
required extra work to reload the 4D password system.
But I sorely missed the “Current user” command. I wanted to be able to use it
in Triggers. I tried several ways to pass this information into triggers and
all were cumbersome and prone to failure in certain situations whereas the
“Current user” command was so easy and always worked. Guaranteed.
So I started using what I call a dynamically built 4D password system. I still
use the [Users] table to lookup if a person is allowed into the database but
once I know the user is allowed in I do this:
GET USER LIST($userName_at;$userNumber_al)
$i:=Find in array($userName_at;$theUserName_t)
If ($i<1) // 4D user does not exist, so create it
$i:=-2 // created by the Administrator user
$i:=Set user
properties($i;$theUserName_t;"";$password_t;0;!00-00-00!;$groups_al)
// pause for 1 second to work around -9978 Bad user password error
DELAY PROCESS(Current process;60)
CHANGE CURRENT USER($theUserName_t;”******")
End if
That makes sure there is a 4D password system user — with the name I want — is
available. If not, I create it and then CHANGE CURRENT USER to that user so
that “Current user” command now works. That’s the primary reason for me to do
all of this.
It is simple and does not require any special saving and loading of the 4D
password system when the database stops or starts.
I’ve now started moving away from even storing passwords in the [Users] table
and doing all authentication with the 4D SSO Active Directory integration. It’s
so simple to use once you clear away the debris surrounding it. Here’s my
implementation and why I do it this way.
First, you must be using Windows 64bit 4D Server v15 R5 or newer and have New
Network Layer turned on. Of course you need all your users to authenticate to
Active Directory using the default NTLM protocol, but it does support Kerberos
if you do some extra setup work. Once you have all that in place, you just
check the “Authentication of user with domain server” checkbox on 4D Server and
setup is done. It is ready to use.
In your [Users] table add a field for the “Windows login name” that a person
uses. Windows guarantees it is unique for a domain. If you want to support
multiple domains you can do that too by adding a “domain” field to the table.
To allow someone to access the database, create a [Users] record with the name
you want reported by “Current user” and the Windows login name that person will
be using. That’s your lookup key.
In "On Startup" you use the “Current client authentication” command to retrieve
the Windows login name that was verified and authenticated with Active
Directory. Use that to query the [Users] table and if you find a match, let the
user in. Authentication is done, no password needed, no checking of any
password, you are doing SSO and you let Windows control the original sign on to
the network and you trust that.
Don’t use “Current system user” command. This returns the same login name, but
it it not guaranteed to be authenticated to Active Directory.
Example: A person could bring in a laptop from home, create a local user
account on that machine with a matching Windows login name, sign in to that
machine with that login and then plug that machine into the corporate network.
They get a DHCP assigned IP address. Then they get a copy of 4D Client, put it
on the machine and launch it. Bang, they are into the database. You can only
trust “Current client authentication” to give you the Windows login name that
has been reliably authenticated.
You don’t really need to store a password in the [Users] table. You are going
to let Windows control authentication. Don’t be afraid of this, that’s how it
is supposed to work.
I do still have a password field in my [Users] table and a special way that I
can log in to the database as any [Users] record using that password. But
that’s only for me and the IT administrator when we need to do testing of
permissions or privileges in the database as another user. That’s the only use
of the password field now. (Of course if you let macOS users into the database
then you’ll have to use this password field and do the “old style” login dialog
box and authentication.)
Seems simple when you see it laid out this way. Too simple. Too easy. Must be a
horrible security risk hiding somewhere. I’ve yet to find it. This is the
documented way of using this system. No saved passwords. Use “Current client
authentication” and you are golden. 4D is doing all the hard work for you.
http://doc.4d.com/4Dv17/4D/17/Single-Sign-On-SSO-on-Windows.300-3743254.en.html
When I first started trying to use this method I made it too complicated. I had
followed an example in the documentation and implemented an “On Server Open
Connection” method that did the authentication and returned an error code and
you had to deal with all of that on 4D Client. I thought you could only call
"Current client authentication” from 4D Server. Not true. Works fine called
from 4D Client. In fact a tech note on SSO— I believe written by Tim Penner —
has an example of doing it that way. So it’s cool. That simplifies the
implementation because it can all be done in the On Startup method from 4D
Client.
This is going to be my standard, default way of letting users connect to 4D
Server on pure Windows environments. Totally eliminates the need to save
passwords in the 4D data file. No need to implement a change password” feature
in your database. No need for a “login” dialog box for the average user.
Tim
*****************************************
Tim Nevels
Innovative Solutions
785-749-3444
timnev...@mac.com
*****************************************
**********************************************************************
4D Internet Users Group (4D iNUG)
Archive: http://lists.4d.com/archives.html
Options: https://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
