I have successfully added ldap-ad to Alfresco. Now when i am creating a user in AD, it is synchronized with Alfresco and i got an Alfresco user. The question is, if a user Bob (that has been sync from AD) changes his password (in Alfresco interface), in which authentication system the password will be changed, Alfresco or AD?
If the password will be changed in AD, then i have no other querstion, but as far as i know, there is only one direction sync, from AD to Alfresco, so Alfresco cant access the AD passwords and change them. Does this mean, that Alfresco will create a password for Bob and store it in its own authentication system and now Bob can loggin with alfresco and AD passwords (new and old)? And most important question: How to avoid that? Thanks in advance.
Alfresco uses an authentication chain concept. That means you can configure more than 1 system for the authentication and if a user tries to authenticate Alfresco steps thru the configured chain and tries one system after the other until the user has been authenticated successfully or if the auth fails on the last chain member the auth attempt is assumed as failed.
Alfresco brings it's own authentication subsystem to create and store users locally in the repo db with passwords. Locally created users like admin are stored in the local subsystem alfrescoNtlm which you could find in the node browser in the user://alfrescoUserStore/ store. That store is for the authentication of internal users only.
"users" you see and manage in the Alfresco UI are of type cm:person stored in the main store workspace://SpacesStore (/sys:system/sys:people/) but do not contain any password at all.
The ldap sync only creates users in the workspace://SpacesStore under /sys:system/sys:people/and once a user tries to login Alfresco walks thru the authentication.chain which may look like in production:
kerberos1:kerberos,ldap-ad2:ldap-ad,alfrescoNtlm1:alfrescoNtlm.
Alfresco Share only provides the user a "Change Password" dialog if the user is found in the local alfrescoUserStore. Alfresco does never change a password in any other system.
To test whether you have understood everything: What happens if a user max exists in the AD and in the local alfrescoUserStore and changes it's password in the Alfresco UI? ;-)
If you were using LDAP for authentication, then the passwords will never store in Alfresco. Passwords will be stored in LDAP and and it will be linked with Alfresco by their email or usernames.
Related
If multiple systems join ldap authentication, then any administrator of any one of them can get the password of any user's account.right？
Applications authenticating against an LDAP directory are not going to be able to access all of the user passwords en mass provided you do not not permit direct read access to the attribute or you do not store your passwords in clear text (if you use something like ldapsearch to dump an entry and have userpassword:: followed by a bunch of random looking 'stuff', that's an easily decoded clear text password). App I allow to access my LDAP server aren't given access to read all of the userPassword values to attempt reversing them out to clear text (and I'm using a decent encryption mechanism to store userPassword value). I restrict the application service account to reading contact-type attributes (phone number, address) and group objects. The only way they get the user's password is by asking the user for it and binding against my directory with those credentials. Can an app admin grab credentials for those who use the application? Sure, they could.
On an out of the box application, I could attach a debugger and access the username/password values as they transit the application. With custom-written applications, it's even easier to grab the credentials. The application takes the username and password as user input and binds to the LDAP server to validate the username and password. As an LDAP server admin, there's nothing I can do to prevent the application developer from making calls and doing other things with that username and password. "Other things" may be legit -- I've handled LDAP directory migrations by authenticating against the old system and, on success, creating the user in the new directory LDAP with the password the old directory just accepted. It was an ugly way to migrate directories, but it worked. "Other things" may be malicious. Is it likely to encounter an app admin or developer who is siphoning off credentials? Depends on who authenticating through your LDAP directory.
This isn't a unique failing of LDAP -- any authentication back-end that you let other people use directly suffers from the same problem. If you don't want the app admins/developers intercepting user credentials, look into federated identify management (FIM) -- an authentication mechanisms where the app (service provider, in FIM terminology) doesn't have access to the username and password but rather validates a token of some sort that was created after a trusted "identity provider" authenticated the username and password.
I use symfony/ldap to authenticate my users in a Symfony4 project against an active directory (on domain controller). Everything works but now I want to fetch the user information from a local database (according to username or email).
In the official documentation (https://symfony.com/doc/current/security/ldap.html), it's written:
... the following scenarios will work: ... Checking a user's password against an LDAP server while fetching user information from another source (database using FOSUserBundle, for example).
But how to do this? How to combine the ldap service for authentication and the user provider (User Entity) for user information?
Best regards,
Jonathan
EDIT: I've created and published a meteor package that integrates the ldapjs node package see accounts-ldap
Feel free to submit any issues or pull requests on the github page
Original question:
Users are authenticated through ldap and I've created a custom login handler that works properly against ldap (Accounts.registerLoginHandler(...)).
Currently, I need to import user accounts on startup. Because I'm using ldap as a 3rd party to authenticate, I won't be able to store passwords for the users. I'm wondering how I can hook in to validate user logins without storing the password.
So the real question is:
How can I authenticate users on login without having a password?
You can autenticate to ldap get user id/name check exist in meteor users than can impersonate that user using:
(In a server method)
this.setUserId(userId);
Where userId is imported meteor userid.
We are developing a self registration app.
Our app allows users to register for web apps and is deployed on a weblogic 10.3.5 app server. The weblogic is connected to a local ldap system.
Once the user registeres with our app we call corporate servces to generate a user id. password activation, authentication is all handled by the corporate servcies. which also has a corporate ldap that contains all users in the company.
The approach works fine for 'new users' ie users that are not present in the corporate ldap or the local ldap: users enter their details and are issued a user id which we then copy into the local ldap once the user activates their account.
The use case we're grappling with at the moment is how to handle 'existing' users that wish to register. These are users that are currently in the corporate ldap and wish to 'register' with our applications. They get rejected during the normal registration process as they already exist in the coroporate ldap.
What i'd like to do is force them to login (simply so they don't register on behalf of somone else) and once they're logged in simply copy their data into the local ldap.
The problem is even if they are successfully authenticated by the corporate service, they don't (yet exist) as far as the weblogic server is concerned. is there a way to obtain the user id that comes with the authentication token ?
The authentication method is SAML 1.1
The application is a standard Java EE servlet based webapp using the struts2 framework.
Any ideas would be much appreciated.
Within WebLogic, you can define multiple authentication providers and set them up in the order you would like the system to use. Since you are copying data over, you would have to programmatically check for the existence of the account before attempting to create it on the LDAP server.
It would be a lot simpler if you use the external LDAP server directly instead of copying the data to the internal LDAP server, letting you attempt logging the user in and creating the account only while catching the appropriate exception.
We have a requirement to get information from specific users on an LDAP directory based on a Smartcard being presented. The application is already running under an AD user account, but using that users access to LDAP will not have sufficient access to the specific users data.
We have stumbled through a few parts of LDAP APIs and not had much luck finding info on how to make an LDAP bind call without username/password and more specifically with auth from a smartcard. Some of the MS LDAP appears to allow the option of using the current user token.
The best we have come up with is to use the SC to login then while impersonating the user create the ldap connecton using the current user token. Similar in idea to this MDSN blog .
Is there a better way?
The problem we are having with the impersonation is that the logged in user has to have certain rights for logging on other users to do the impersonation. Also while impersonating we need to limit other interactions, accessing the file system or registry as the alternate user is not desirable.