On Sep 6, 2019, at 06:15, Jörg Knebel via 4D_Tech <[email protected]> wrote:
> Arrgh, do you rely believe trusting/relying on an outside “system” is worth > even considering? > > Please think again, and than think different and again… > > Just as a warning, “Active Directory” and everything coming from Microsoft - > use at your customer risk… Sounds pretty harsh considering 90%+ businesses in the world use Microsoft Windows and the built in authentication system, and I’ve not heard of any serious concerns. You have to log into the Windows workstation somehow. Most use what Windows provides and turn on the password restriction options. But as I read posts from so many people, nobody has mentioned 4D’s support Single Sign On (SSO) on Windows. I find this to be a great solution for moving all authentication out of 4D and just relying on Windows. Enterprise is already relying on Windows authentication to allow all the users to log into their computers — and manage the passwords — so why not do the same? Here is the long story for those that don’t know the details of using 4D’s SSO authentication. I have 1 client that I switched from using my own table based user authentication system. Worked out fantastic! Typical setup where you present your own login dialog box and require a user to provide a user name and a password. Then go query the [Users] table for that user name and validate the password they provided with what is stored in the [Users] record. If you switch to SSO — and you can only do this in a pure Windows environment — you eliminate the need to store any passwords in the 4D system. They are no longer needed. All that is needed is a valid Windows login. Just store that in the [Users] table. Here is how it works: First you must run 4D v15 R5 or later version on a Windows Server. Must be 4D Server 64bit. Must have the new network layer enabled. And of course you must be on a network with Windows authentication — the normal NTLM is fine, but it also supports Kerberos. That’s a Windows domain server that does the authentication. On 4D Server check the “Authentication of user with domain server” checkbox. That will turn the system on and make the “Current client authentication” command function. https://doc.4d.com/4Dv17/4D/17.2/Current-client-authentication.301-4387315.en.html In the 4D Client “On Startup” method you call the “Current client authentication” command and it returns the “Windows login” value for the currently logged in user. You can do this on the 4D Client machine, you don’t have to execute on server. (The documentation makes it seem much more complicated than it really needs to be.) The command will provide whatever Windows login was used to log in on the machine. So for me it might be “timnevels”. I query the [Users] table for a record with “timnevels” set as the Windows Login and if found I am allowed to connect to the database. If “timnevels" is not found in the [Users] table I you just QUIT 4D and 4D Client is prevented access to the database. It’s really that simple. The beauty of this is that you can TRUST that “Current client authentication” will return a valid Windows login that has come from a user authentication to the domain server. Say “bobjones" brings his laptop from home to work. He wants to log into the database as me, “timnevels” so he can do nefarious things. He knows he can connect his laptop to the company network and it will get a DHCP IP address. He copies over 4D Client to his laptop. He creates a local account on his laptop with Windows login “timnevels” and a password he knows. He logs into his laptop with that account. He starts 4D Client and attempts to connect to 4D Server. When 4D Client calls the “Current client authentication” command, it DOES NOT return “timnevels”, it returns “”. That’s because Bob did not authenticate to the company’s domain server. The “Current system user” command returns “timnevels” on Bob’s machine, but you can’t TRUST that as an authenticated Windows login. My client can now enforce password restrictions for the Windows login and 4D doesn’t have know about it or bother with it. No need to encrypt passwords in the 4D data file. When a person quits the company, they simply deactivate his Windows login on the AD domain server and then go into 4D and remove the person’s [Users] record. So what am I missing in using 4D’s SSO feature. Seems great to me. Could not be any easier to use. Tim ***************************************** Tim Nevels Innovative Solutions 785-749-3444 [email protected] ***************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
