Background
Another team within our organization has a fully configured Active Directory server. My team builds Ruby on Rails applications and we authenticate users of our web applications against their setup. Due to some new security policies that are being put in place, our development machines will no longer be able to talk directly to the production servers. As a result, I'm trying to install OpenLDAP on my local machine (running Fedora) and use that to authenticate users when I'm developing.
Setup
I have been able to fully configure OpenLDAP and insert a record. My database looks like:
dc=dev,dc=com
ou=Users
cn=User 1
Inside the cn=User 1 entry, I have an attribute called accountName and I also have the standard userPassword attribute. As a test, I downloaded an LDAP browser and I'm able to successfully authenticate when I specify the full DN (cn=User 1,ou=Users,dc=dev,dc=com) and give the password that's in the userPassword field.
Question
In our production environment, all I have to give for authentication is the base DN (dc=dev,dc=com), the value for an accountName and the associated password. Once I authenticate, I'm able to access the other fields in the User 1 entry. What do I need to do to authenticate using the accountName field instead of a full DN?
There are two things to address here:
First off, if your production environment is ActiveDirectory and you can't access it from your developer workstation, ask the team in charge of the AD environment to create a "dev" environment that you can access.
While the basic concepts of LDAP are standardised, the implementation specific details will vary greatly between AD and OpenLDAP.
Secondly - the way that most^ software is able to authenticate against LDAP using just a username and password is thus:
User: submits a form (web, native app, whatever) with their username and password
Login process: binds to the LDAP server, either anonymously, or with a fixed service account DN and password.
Login process: does an LDAP search for the supplied username, matching against which ever attributes are relevant for the environment (e.g. "accountName" in your case)
Login process: fetches the DN of the found record (if any)
Login process: attempts an authenticated bind using the fetched DN and the supplied password from step 1.
Edit:
^ In some situations, the username supplied is the value component of the user's RDN, e.g. if my login is stephenr, my user entry's RDN might be cn=stephenr. If this is the case, and all user entries have the same parent object, the DN to authenticate as (step 5 above) can be created just by building a string, e.g. "cn={userid},ou=users,dc=example,dc=com" where {userid} is replaced with the supplied username value in step 1.
Related
So i have Symfony 4 app which should allow login via LDAP and based on your groups modify some of the values in this ldap directory.
The Login itselfs, and mapping from Ldap Groups to ROLE_ works perfectly.
The idea was that only the currently logedin user does a modification. Not a hidden Directory Admin.
For this i would need to $ldap->bind() with the user credentials each time a loged in user wants to modify the directory.
But for this i would need the password. The only way i could think of, would be to save the password in the session - but form a security standpoint this would be a very very bad idea.
Is there any other way? Like store the already binded connection somehow?
As far as I see in the Symfony security component - the UserProvider only refreshes the user from sesison - without calling ldap again.
The LdapBindAuthenticationProvider only uses the ->bind() call with the given credentials and catches an exception if password doesnt match.
But the connection itself is a simple fire & forget.
I have a Wordpress/WooCommerce installation using Wordpress itself for authentication. I want to switch to LDAP-based authentication (e.g. OpenLDAP). How can I migrate existing users with minimal intervention on their part?
Ideally they would simply continue using their pre-existing credentials for Wordpress and for any other resources using the same LDAP database.
In addition, new users created via WooCommerce purchases should be created as LDAP users.
(Existing plugins like Simple LDAP Login seem to handle creating Wordpress users for pre-existing LDAP credentials just fine. I'm looking for support in the other direction.)
I think you'll have to develop this task yourself. You could check tools like : https://lsc-project.org/start which will allow you to configure mapping and synchronising SQL database to LDAP directory and schedule the task regularly (or trigger it on new row in the DB)
Only point where you could have some problem would be the "keep their credentials". I don't know wordpress, but if the hashing and/or crypting mechanism of the passwords are not natively supported by OpenLDAP, you will have to hash the clear password of the user to store it with a mechanism compatible.
One way would be to tell every user that the password will be reset and that they will have to retype it (some custom landing page where you authenticate the user with his credentials on the wordpress DB and if successful write the password on the LDAP)
Another way would be to deploy some self service password with all account reset and a need to re-set them with a link send to their email (from the LDAP). There are tools like that, for example : https://ltb-project.org/documentation/self-service-password
Follow Esteban's advice I developed a solution as follows:
Wordpress interface
Install Simple LDAP Login
Install JWT Authentication for WP REST API
Users authenticate against LDAP, fall back on Wordpress
"Change password" sends them to new interface
New interface
User logs in via new interface
Users authenticate against LDAP, fall back on:
Authenticate against Wordpress via JWT. On success:
Create LDAP user (we have the password)
Delete Wordpress password hash (no longer needed, forces LDAP-based authentication in future)
Workflow
Existing users can sign in via Wordpress or the new interface. Once they use the new interface (to sign in or change their password), they are migrated to LDAP-based authentication.
New users are registered in LDAP. They can sign in via Wordpress or the new interface, both backed by LDAP.
I'm developing an ASP.NET MVC application. I need to support multiple authentication mechanisms (this app is used by multiple customers, each with their own preferred authn provider). One auth provider will be Active Directory. The AD integration for authentication is straightforward and I have no problems with that.
For authorization, roles will be stored in a local database (NOTE: we cannot use Active Directory groups for doing authorization - roles need to be local application roles because we support multiple authn providers and AD admins won't want to create custom groups in AD just for our app). My expectation is that we will need to create "stub" user accounts in our local database in order to do the User-is-assigned-which-Roles mapping. These stub user accounts will also be used to indicate which users are authorized to access the application (not everyone in the AD database should have access).
The anticipated flow of control will be:
User accesses login page > enters credentials > posts credentials to app server.
The app validates the credentials against AD. At this point, we know if the user is authenticated.
The app checks the user's SID to see if a "stub" user account with that SID exists in the local database. If not, the app displays an "not authorized" error message to the user.
The app will look up roles for the user in the local database user-is-assigned-which-roles table.
User identity info including roles will be stored as claims and the app will use typical claims based authorization (i.e. ClaimsAuthorizationManager).
My question is what is the best way to create "stub" user accounts into my local database? My guess is that we should use some sort of AD export script to export AD accounts for those users that should be granted access to the ASP.NET app and then import those users into the local database (NOTE: I expect that the stub account will contain minimal info - perhaps just the user's SID from AD and maybe the username).
A batch export/import is probably OK as an initial deployment process. After the app is up-and-running and new users join the organization, I expect a more user-friendly mechanism will be desired for granting a new user access to our app (other than exporting/importing the new user's account from AD to our local database). My guess is that we'll need some sort of user browser screen so that an admin in our app can browse the AD directory, select a user, click a button and then have that user's "stub" account created automatically in our app.
Has anyone implemented an application with similar requirements? If so, how did you bootstrap the creation of "stub" accounts in your local database? Is there a better way to address these requirements?
Please feel free if this can Help You Custom Annotation Authorization
It's only a workaround, or just an idea, not a solution...
To use it you only need to use Annotation in the controller
e.g.
[ARQAuthorize]
public class BlaBlaController : Controller .....
I am currently implementing a similar solution. Here is how the application works. I'm using ASP.NET MVC 5, ASP.NET Identity 2.2.1.
I am using the Identity framework to manage users and roles within the application. The user goes to a login page, enters their credentials. The application checks against the application DB to see if the user exists. If not it throws an error that the user doesn't exist in the database. If the user exists, it authenticates against AD. If authentication fails they get an error message, if it doesn't fail I create a ClaimIdentity from the user out of the database (not the user in AD) and pass that to my SignIn method.
My user in the application DB has the same username as the AD username and I use that as my stub. I also include the domain of the user in the DB as well in the case that I might have multiple domains I need to support. With Identity, don't forget to also populate the SecurityStamp field with a guid.
The plan is to bulk import the users and permissions from a spreadsheet and I have some standard CRUD actions created to allow creation of individual users and assigning of roles after that.
After referring so many forums, I am able to authenticate and sync active directory users to alfresco. The problem is we have more than 25,000 users and rite now we are planning to open alfresco only for selected users. Whenever someone search people they will be finding all the 25,000 users who are not even using alfresco. My It team is not willing to create seperate group for these selected members. Is it possible to sync only users who are logged in.
I am using alfresco 4.2e Binary Installation. Windows 7 64 bit.
The most easiest way would be to distinct users to sync via LDAP query.
You could find this link useful.
This scenario should do it:
enable ldap authentication
configure the authenication chain to include Alfresco and LDAP. This will ensure to try to authenticat against both systems. e.g.
authentication.chain=alfrescoNtlm1:alfrescoNtlm,ldap-ad1:ldap-ad
disable sync
# This flag enables use of this LDAP subsystem for user and group
# synchronization. It may be that this subsytem should only be used for
# authentication, in which case this flag should be set to false.
ldap.synchronization.active=false
If you start Alfresco the very first time there is no user in Alfresco. Depending on your strategy how to control the user creatioin you could ether:
create user manual
If you're running on linux the easiest way would be to use the alfresco-shell-tools otherwise you could use the csv-import feature in the user admin. The trick is to use the same username so Alfresco will try to authenticat against both systems before it fails.
create user on first login
Another way is to enable implicit user creation on first login. This isn't my recommendation since you will get trouble later because the user has no email address configured / no user info is synced. (This way is not tested - if this doesn't work you may define a sync query which doesn't return users to enable sync)
synchronization.autoCreatePeopleOnLogin=true
you will get the auto-creation of people who were successfully authenticated but weren't brought in by the sync
you need to add/change this line also on ldap-authentication.properties :
ldap.authentication.active=true
ldap.synchronization.active=false
ldap.synchronization.autoCreatePeopleOnLogin=false
synchronization.syncOnStartup=false
synchronization.syncWhenMissingPeopleLogIn=false
and add on alfresco-global.properties :
create.missing.people=false
So I have set up a IIS 7 server with windows authentication, and all works well. I have an aspx (test page) returning the users name and groups.
Code:
IIdentity WinId = HttpContext.Current.User.Identity;
WindowsIdentity wi = (WindowsIdentity)WinId;
string userDomain = wi.Name.ToString();
the userdomain string returns (example) "DOMAIN/username"
however, I have only one user on my domain (same active directory groups as similar users) but he returns "Server/administrator". I checked all the groups in security and he doesn't belong to them. So im out of ideas.
EDIT: See my answer below (figured it out)
There are two places storing user accounts, local SAM store and Active Directory.
If you see "Server\username", it means you have logon to the machine using an account from local SAM store.
If you see "Domain\username", it means you have logon to the machine using an account from Active Directory
The confusion usually comes up when you have a local user account with the same user name as a domain user account. The built-in account "administrator" is usually one of the most common accounts causing this confusion.
In order to make sure you logon using a domain account but not a local user account, you can specify fully qualified name at the logon time. e.g. Domain\Administrator or Server\Administartor
Figured it out. He had a certificate attached to his user account that didn't get destroyed when using remote desktop connection. Thanks anyway.