I have some users that have had no problems at all in the past. All of a sudden they can't log in anymore. Nothing has changed in the OUs in Active Directory. All other users can log in, no problem. It's just these two. The only thing I can see is in the 'field_data_ldap_user_current_dn' table their 'ldap_user_current_dn_value' got set to null. I manually set this in the db back to the correct dn, but this didn't help. How can I get these users their access back?
Edit:
Whenever cron gets run these two users get their DNs nullified.
I don't know if there is another solution, but I had to delete the users account and assign their content to anonymous. Then they logged in using LDAP credentials and the account was created successfully. Then I just had to assign their content back to them.
Related
I work in a lab where we have a desktop that we allow researchers to remote into and use for working with their data. There hasn't really been any policy to keep the machine clean except telling people to clean up after themselves, and after years of use we now have completely full hard drives. The machine is on a university domain, but we are a somewhat separate non-profit entity so we aren't supposed to be using the university tech support / IT help...
There are approx 30 user folders on the machine, and about 10 people who currently have remote access. My plan was to delete any user folders with a LastAccessTime before 1 year ago. User folders correspond to university IDs, and so I was able to email users and notify them (although many emails were no longer valid).
So I ran a test with a new user to see what would happen and I'm a little confused by the results. Here is what I did:
Gave RDP access to a new testuser account. Confirmed that there was no user folder for testuser under C:\Users.
Logged in with that test user, and a C:\Users\testuser folder was created
Logged in with an admin account and deleted the C:\Users\testuser folder
Logged in with the testuser account and received an error ""We can't sign into your account. This problem can often be fixed by signing out of your account and then signing back in.
If you don't sign out now, any files you create or changes you make will be lost."
I logged out an in again with testuser and received the same error. I'm wondering why initially when there was no user folder, one was created when I logged in. I assumed after I deleted the user folder, a new one would be created the next time I signed in, but apparently that's not the case?
I didn't really want to dig through all of the user folders to find data and delete it, and I don't think we need to keep all users, but I would like users to be able to remote into the machine again and have a "clean" user folder created if their old one was deleted and they still have RDP access.
Any guidance on the best way to clean up our machine is appreciated!
I have tried multiple times to get this to work, but I haven't figured it out yet, so I'm asking in here, hoping that someone will be able to help me out.
I am using Atlassian's Bitbucket, Jira and Bamboo and they're all synced with an AD. At the moment I am using my AD user to retrieve all the other users. It works, but it's not optimal, as the password expires every three months, and I have to change the LDAP user login info on all three applications. We have ordered a Service User, where the password doesn't expire, but the problem is that the Service User is in another group.
The picture below shows how the AD is set up. My Service User is in a group called Special Users. I would like to use this user as the login user in the settings. This way I would never have to think about changing password, when my AD password expires.
I would then like to retrieve all the users from the "Normal Users" group.
Let me know if more information is needed.
Thanks.
You could also add multiple user directories pointing to different parts of your Active Directory.
Jira has an internal Crowd out of the box.
You may let Jira connect to User directory and let all other application use Jira for authintication.
This would save time by only updating your LDAP password every 3 months on 1 application and reflected on all 3 applications
I'm trying to use WSO2IS with an Active Directory LDS.
Using the store to display and read users is no problem.
However when editing a user, there's a hiccup.
The users are situated in OUs in the AD and in the synced AD LDS.
(We use the AD LDS to add user attributes without changing the original AD.)
When I edit a user it will be moved by the IS to the UserSearchBase.
IS is still able to show the user - for now.
When the AD LDS is synced with the AD, the user will be moved back to its original OU.
The IS will not be able to find the user, because it is still looking for the user in the "new" location in the UserSearchBase root.
Only if I restart the IS, the user will be found again.
I tried to recreate the behaviour by hand:
Create user in an OU situated in the UserSearchBase
Edit the user with IS
Move the user back to its original location in the OU in the AD
IS throws error
Is there a way to tell the IS to leave the user DN/location as is?
Is there a way to disable caching? (Without impact on performance?)
Regards,
Mat
This looks like a known issue with Cache Expiry Bug 6471. Please see if the description matches your exception trace.
There is a fix going on for the above. That will be available on future release.
You can also build from the public repository once the fix is done, if this is the case.
Workaround
You can edit and save the user store, if his user store is configured with the UI. You do not need to change any value. This will cause a new instance to be created, thus re-creating the cache.
I'm building a Laravel website and I'm using the database driver to manage sessions. I created the sessions table in database and migrated with php artisan. Everything works as expected.
What I really want to do now is to check the role of the users that are online but I don't know how to get this with the fields of the sessions table in the database.
I don't really understand how the sessions table work, because I see that it registers a new row when I access to the login page, but it doesn't change when the user has logged in and when the user has logged out.
All I wanted is to check the role of the users active in the app....
Someone can help me with how to get to this?
Thank you!
I suggest you a very simple way. Just in your users table add a field called "is_online" that is 0 by default. When the user logs in , just change it to 1 and when he logs out change it back to 0. So DB::table('users')->where('is_online' , 1)->all() returns the online users.
I have an Azure Active Directory (AAD) set up in my Azure subscription associated with an email address of mine, which we'll call A.
Some time later, I updated my Microsoft Account to use a new email address B as the primary email address, with A being associated with it still so it can still be used and the two email addresses treated as being one.
In AAD there is one user, whose user Id is A which appears not to be able to be changed as it is greyed-out. Attempting to add B fails with the error: You cannot add yourself.
Is there a way I can force the user name of the AAD user to be B instead of A?
The reason I ask is because I am trying to setup an Azure Key Vault in my subscription as it appears to be failing because whether or not I sign in as A or B in Azure Powershell, I am always signed in as B. This then causes this error message, which I appear to be unable to work around:
New-AzureKeyVault : Cannot find the Active Directory object 'B' in tenant
'{Tenant Id}'. Please make sure that the user or application service principal you are
authorizing is registered in the current subscription's Azure Active directory. The TenantID displayed by the cmdlet
'get-AzureSubscription -current' is the current subscription's Azure Active directory.
Can you check that you are using the latest bits for Key Vault PowerShell?
I talked with some folks internally and we believe that an experience like this may be expected if you are using an older version of the PowerShell CMDLETs, but the lastest version should be update to date and not run into the issue you are having.
If you find that you still hit this issue after upgrading, we may have a bug on our side that we should fix.
In that case, my suggestion is for you to create a new Admin User. Then delete the old Admin Account (you may need to Transfer Onwership of your AAD Subscription to the new Admin), and then recreate your account, which will pull the lastest information from that user.
However, I only reccommend trying this after having updated the PowerShell bits.
Please let us know if either of these methods resolves your issues.
Thanks,
Shawn Tabrizi