Jump to content

Search the Community

Showing results for tags 'active directory'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Essentials
    • Announcements
  • Passwordstate 9.x
    • General Support
    • General Hints and Tips
    • Known Issues
    • Installing Passwordstate
    • Feature Requests
    • Feature Requests - Completed
    • 3rd Party Hardware/Software Knowledge Forum
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • App Server
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 8.x
    • General Support
    • Feature Requests - Completed

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 5 results

  1. Hi, As an admin I want to have ability to enable/disable security group for syncing non-existent users to Passwordstate if global sync of non-existent users to Passwordstate is enabled. Goal is to have just one exact group called i.e. "Passwordstate Users" which will sync all non-existent users from AD to passwordstate to automatically enable them access, but not to anybody else in any other group. We have several groups like "DevOps" which contains not just devops engineers, but also their scrum master. Scrum master must not have access to passwords anytime. It's same for all other engineering teams, there is always at least one person which must not access passwords, but rest of teams must access all passwords shared to team. I can imagine that on each Security Group imported from AD will be Flag which will be possible to enable or disable and will achieve required scenario. I.e. by default it will be enabled, but as admin I will be able to disable sync during importing process (or later enable/disable). Something like screenshots below. In this case I think it will be very easy to implement, because it’s just a flag in one table and enhancement in AD Sync which will check for each group if it shouldn’t be skipped. No need to change rest of sync process. I think much more people will benefit from this.
  2. Hi, Passwordstate currently sync just Security Groups members, but nothing else. As an admin I want to get synced all AD user attributes into Passwordstate anytime it's changes in AD by schedule. (i.e. first name, last name, email, username, department, office, etc...) Thanks
  3. Hi ! I have PasswordState 9 (Free 5 users) and everything runs smooth except 2 features and this topic is for one of them. The dependencies discovery. I try to use the PasswordState powershell script that's called "Discover Windows Account Dependencies". When I put the list of our servers and precise the identity, the script seems to work but for an unknown reason, some servers just don't return Scheduled Tasks. Even 2 identicals servers (like load-balancing's ones) which are supposed to be identical... Don't behave the same way... For exemple, SRV1 and SRV2 are supposed to have similar configuration. SRV1 returns it Scheduled Tasks and SRV2 returns : "Cannot call a method on a null-valued expression" I am not a developper and this issue just surpass my skills... Does anyone have any idea about how to troubleshoot this ? Ever encountered this ? Or anything that could help us to get a relation AD Account <-> Scheduled Tasks (per Host) Really appreciate any help, thanks ! ----------------------------------------------------- Edit : Wrong version of General Support (PasswordState 8, I wanted v9...) Mea Culpa
  4. Issue: Some customers can run into different issues relating to sync'ing active directory accounts in Passwordstate. This can quite often be caused by custom permissions on AD Objects or containers. Suggestion: One way to quickly rule out if permissions are causing the issue, is to elevate the Passwordstate Privileged Account to be a Domain Administrator, and then try to reproduce the error. To find and elevate the Privileged Account, please follow these steps below: Step 1: In Passwordstate, under Administration -> Active Directory Domains, open your domain and look for the Privileged Account being used: Step 2: Again in Passwordstate, go to Administration -> Privileged Account Credentials, and open the Privileged Account you found in step 1. Take notice of the account name: Step 3: In Active Directory, open the account you found in Step 2, and add it to the Domain Admins Group: Now try to reproduce the issue you were originally having, and see if the problem persists. If this resolves the issue try investigating the permissions on the AD object, or container where it resides, to see if you can work out why a normal account cannot query it. Once this test has finished, we'd recommend removing the Domain Admin privileges from your account again. Regards, SUpport.
  5. Issue: We've had a few reports of customers who have not been able to sync AD Security Groups, or possibly not able to add users into the system from Active Directory. Symptoms: Some symptoms you may see is when adding in a AD Security Group, it will not enumerate the members. Or possibly you might be presented with a Error page in Passwordstate saying it cannot query Active Directory. Possible Cause: By default, Passwordstate only requires an account that has "Domain User" privileges in AD to be able to sync objects, however if you have hardened Active Directory to minimize the visibility of containers for certain users, you may need to elevate the permissions for your Privileged Account. How to Test: As a temporary test, add your Passwordstate Privileged Account to the "Domain Administrators" security group in Active Directory. If this resolves the issue, then this indicates it's a permission issue. How to Fix: Unfortunately every AD environment that has been hardened can be different, so it's difficult to say exactly where the issue lies. Normally when companies harden AD they may remove the ability for the "Authenticated Users" on certain containers to hide them, but some applications built with standard .NET code can have issues with this, including some of Microsoft's. We would suggest you check permissions for each container starting with Users and Computers, and confirm whether or not the Authenticated Users has read access, as per below screenshot: Next, you should check any other container that you have computers or user accounts stored in for the same permissions above, and this will include and nested containers, as the problem may be caused at any level. Finally check the top level domain and then depending on the results, you can do one of a few things: Restore the default AD permissions to allow Authenticated users to have read access to all containers where you have users or computers, and also ensure the permissions filter down to all nested objects - We realize this may not be possible. Give your Privileged Account Read access on all containers, and ensure permissions filter down to all nested objects Elevate the permissions of your Privileged Account to one of the built in AD Security Groups. Suggestions are: Account Operators, Administrators, Domain Administrators or Pre-Windows 2000 Compatible Access More Information: You may possibly run into the same sort of issues in Passwordstate, when attempting to let Passwordstate reset a password for an Account in AD. For most accounts in a domain, the privileged account Passwordstate uses should only need to be a member of “Account Operators” built in security group to be able to reset the passwords. However, this won’t allow the account to reset passwords for higher privileged accounts like Domain Administrators, or Enterprise Administrators. To reset passwords for accounts like these, the privileged account must also be a member of one of the Administrator Groups, either “Administrators” or “Domain Administrators”. This is by design from Microsoft, because if you can reset a domain Administrator password, then you effectively can use that account to perform domain admin tasks, so why not just make it a member of the Domain Admins in the first place? There are ways to set granular password reset permissions on account attributes, which will allow an account with less privileges to reset a domain admin password. We would not like to provide advice on this though as you can imagine it could be different for every domain. So summary, your privileged account should be a member of "Account Operators" group for all normal password resets, or “Administrators” to reset passwords for any Administrator type account. To mitigate against the risk of having these high privileges for your account, you can configure your privileged account to reset its own password on a regular basis in Passwordstate. Just link it to a password record from within the Privileged account screen, and set it to reset as often as you like. If you still find you cannot perform sync's/ resets, please contact Click Studios on support@clickstudios.com.au and if we have any more current information about this, we will let you know. Regards, Support.
×
×
  • Create New...