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.
Related
I am wondering if there is anyway to check if the entered username and password is correct despite of enforcing multi factor authentication in Azure Active Directory?
I have set up an app with application permission(with admin consent) as well as delegated permission and is able to test both approach using ConfidentialClient and PublicClient using MSAL library.
I am not able to run my web form app in IIS with the PublicClient approach which is interactive and displays you a popup for the Microsoft login. So, the only approach I see here is to use app-only authentication.(https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-authenticate-an-ews-application-by-using-oauth )
I can use the confidential client(app only) since I have all the required admin consents granted to get the OAuth token and then impersonate the user to access to EWS managed api.
But the requirement is the user should enter their outlook password in the webform app before loading their emails(from EWS Managed API which needs OAuth token).
At this point I am not sure what to do next. Please help. Also let me know if you need more information.
For more reference why I am no able to use delegated authentication: Why app is throwing error in test environment but working fine in local machine using ASP.NET Web Forms and MSAL?
Per my understanding, you want to check the username and password by Azure AD first and using the confidential client to call APIs on behalf of the user.
This way is something hacking, but I think it works for this scenario. Just try the request below:
POST https://login.microsoftonline.com/<tenant id>/oauth2/v2.0/token
Request Body:
client_id=<confidential client app id>
&Client_secret=<confidential client app sec>
&grant_type=password
&scope=https://graph.microsoft.com/user.read
&username=<username>
&password=<password>
If the user typed the wrong user name and password, the response would be:
If username and password are all right, the response report the MFA related info:
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.
I have an ASP.NET Core 3 web app hosted on an Ubuntu server using Apache.
The app has a login, where the user provides a username and password, and we authenticate against an Identity Server.
In the login flow (in the Identity Server), we check if the user exists in Active Directory (by using the Novell.Directory.Ldap nuget package), if it does, then we retrieve the user data and create the corresponding token, otherwise, we go to our database and check if the user exists there.
This login flow works properly, but there is a new requirement that says that we need to implement a Single Sign-On. So if the user is logged with an account that is asscoiated to the Active Directory domain, then, the user is allowed to access our web app without providing username / password.
At first, I thought that maybe we could automatically retrieve the username in the client app and provide that username to the identity server without a password to finally query Active Directory to check if the user exists. The problem is that I'm not sure how am I supposed to retrieve that username....
Is there any way i can retrieve the Window's username from the client app?
Thanks
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
I have a web application built using React that has an existing User/Session system. Right now, username and password are passed to server to authenticate and create session.
Enter Facebook Login (web). I want to allow for both username/password and also Facebook Login. So, now Facebook Dialog box appears and users can connect. I now receive the Facebook User Id and access token (short-life) on the client side (not the server side). How, now do I authenticate this user on my existing system and create a session?
If I use just the user id, this reveals a security issue (anyone can authenticate with a known user id and get a hijacked session). The short-lived access token is just that, short-lived. So that can't be used as an effective "password". So, what is the best way to securely authenticate someone on my existing login system if they've authenticated themselves via Facebook.
Thanks so much.
Found another user with the same issue here. It was resolved by the following:
The Facebook login request returns user id + short lived access token (client side).
Use the server side Facebook SDK to check the validity of the access token (will return user_id and app_id fields if valid).
You can trust the user_id field returned from the Facebook API to check against your existing user database.