On Jun 12, 2017, at 2:52 AM, Welsh Harris wrote: > I am curious about this as well. > > We are using 4D as a web server. We are being provided the Active Directory > SAM-Account-Name and password for a user. We do not have the user passwords > stored in 4D and need to validate their username/password against Active > Directory. > > Is there a way to login to Active Directory using 4D's LDAP LOGIN with an > admin/service account and then validate the username/password of other users > by using 4D's LDAP Search? > > If not it seems the only way is to attempt an LDAP LOGIN to validate a given > username/password. It seems like that is what some other delegation services > are doing but I might be mistaken? For example:
The way that I understand it is you just need to verify that the user has access to the 4D system. You want to use the company’s Active Directory (AD) to store this information. You will use LDAP to query AD for this information. That’s basically what you want to accomplish. IT Administrators handle updating AD. When someone new is hired they create a new AD entry for the user giving them a user name and password. They also indicate what shares the user has access to, telephone numbers, addresses, the department in the company the person works for, the supervisor name, etc. You can store a lot of information in AD if you want to. So you just want to include one more piece of info for the user — can they access this 4D system. To use LDAP you need a user name and password to access the system. This IS NOT the user name and password of the user you want to verify has access to the 4D system. You use a user name and password that provides access to AD. Then once you have connected to AD you can query for the information you want. Next you need to decide how you want to store “this user can access the 4D system” information inside AD. Here are a couple of options: - Choose an existing AD attribute and store this information in. For example “otherPager” attribute. It’s not being used for anything now, so if the user can access the 4D system put “4D” in the “otherPager” attribute. Then when you query AD for the user name you get the value of “otherPager” and if it contains “4D” you know the user can access the system. - You create a “Custom Attribute” in AD to store the 4D access information. Maybe you give the attribute the name “accessTo4D”. Then you set that attribute to something for users that can access the 4D system. https://social.technet.microsoft.com/wiki/contents/articles/20319.how-to-create-a-custom-attribute-in-active-directory.aspx Since AD is a secure database that only a trusted few can modify you can rely on the information being correct. I don’t really see a need to storing a password to the 4D system in AD. You certainly could do that, and when you query AD with LDAP you can get the 4D password stored for the user and you could validate that. But then you have to deal with handling changes to the 4D password. When do you change it in the 4D system? When/how do you make sure it gets updated to the same value in AD? Here is where 4D’s new single-sign-on (SSO) feature fits in. 4D can now provide you with a verified accurate Windows Username for the current user. The username is guaranteed to be already validated and verified with AD. The user has already provided a valid password for the username and logged into the computer. Here is the situation you want to avoid. Say you have a username of “timnevels” setup in AD. Someone knows that’s my username, but they don’t know my password to log in to my Windows account. So they bring to work a laptop from home and they create an account on that laptop for “timnevels”. They use whatever password they want — it’s their personal computer. Now they plug it into the company network. From their fake “timnevels” account they start up 4D Client and connect to 4D Server. See the problem… it looks like the real “timnevels” is logged in, but it’s really a fake “timnevels”. The new 4D SSO feature prevents this kind of spoofing. Also it allows all querying of AD to occur from the 4D Server machine instead of happening from each 4D Client machine. I have plans this summer to upgrade one of my clients to v16 and use SSO to verify access to the 4D System. I’ll work with IT to have them set up a group of custom attributes that my 4D system will use. I will move all my permissions and privileges that are currently stored in the 4D data file into these AD custom attributes. Then it will become ITs job to maintain this information. And that is actually what they want. They want complete control of what a user can do. What shares they can access, can they access the 4D system, what tables can they access in 4D, can they delete records, etc. So when the get a new user they will setup all the 4D system access information in AD when they create the user’s account. And when they terminate the user, it will automatically turn off all 4D system access. At least that’s the idea... Tim ******************************************** Tim Nevels Innovative Solutions 785-749-3444 timnev...@mac.com ******************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
