how to unlock accounts that meet certain conditions - powershell

I am trying to unlock several accounts in Active Directory through PowerShell, but I can't figure it out how to link every condition into the query
The conditions are:
-The account should be enabled
-It shouldn't be "memberof" some groups (whose I'm not able to unlock, like Administrators)
I don't have full control over accounts, I'm not able to unlock some of them, due to my privileges, so I'll be very helpful if can you help me to know or simple discard the accounts that I'm not able to unlock
I've just tried this
Search-ADAccount -LockedOut | Unlock-ADAccount
(Very poor attempt, i know, I'm very new on this technology)
But gives me an error because of my account's privileges
It says: access rights are insufficient to perform the action.
The error is the same for different CN accounts

But gives me errors because of my account's privileges
That 's' in "errors" is key. If you're getting more than one error, that means that errors don't stop it from continuing on to the next account. That is, actually, how PowerShell works by default.
So what you are doing is already working the way you want it to: it is unlocking all the accounts that you have access to.
Of course, this is just a band-aid on the real problem. It won't eliminate calls for the problem accounts, and it undermines the added security you get by locking accounts in the first place.

I'm able to unlock some accounts, but when I run the command
Unlock-ADAccount, I think it try to unlock accounts like
administrator, some disabled acc, for which I don't have permission to
modify, but if I run that command on an individual "regular" account,
it gets unlocked
This due to the blocking of inheritance of permissions applied to domain Admins accounts & due to Security Descriptor propagator (SDPROP)....
It's not recommended, as it's a critical mechanism in my opinion, but you might :
create a specific delegation for a group
and append this group to the Access Control Entry (ACE) of this kind of template folder for admin permissions: 'CN=AdminSDHolder,CN=System,DC=example,DC=com' (with the help of LDP.exe)

Related

Provide all users with ability to edit their own specific attributes in Active Directory

I've been working on a project that allows users in our domain to edit 3 Active Directory Attributes on their own Object, this has been written in Python and the only issue I have now is user permissions on these attributes.
Two of these are custom, the third is the Location(physicalOfficeDeliveryAddress).
I have looked everywhere and only found documentation on how to give permission for users in a group for these attributes but for ALL users or limited by group.
I'm looking to apply the permission under the Identity Reference: NT AUTHORITY\SELF so that users may only edit their own attributes.
In less words, I'm looking to write a script that will delegate permissions for three specific attributes to ALL users in the domain but only for themselves(NT AUTH\SELF).
I have a loop that will perform it for each user, I just have hit a brick wall in what to include in the loop..
Any help would be appreciated.
NT AUTHORITY\SELF is one of Windows' well-known SIDs, with a SID of S-1-5-10.
So you do it the same way you would for any other account, but grant the permissions to S-1-5-10 instead.
If you show us the code you're working with, we might be able to help you with where to plug in that value, if you need.

why is the enabled flag false for some users?

I tried Get-LocalUser on powershell to see a list of users I observed few users have enabled as "True" and few as "False". Why?
Well these are accounts for users of certain type, and have particular usages. Take the Administrator, for example. It is disabled by default because it has higher level privileges and can potentially perform disastrous operations if not used with caution. The enabled ones, are usually the ones that are created by the user of the computer (the ones shown in the login screen).

Running Convert-MsolDomainToStandard to de-federate

We're about to de-federate our Office365 domain from using adfs2.0 to using passwords sync'd with Azure AD Sync.
We understand the process to need us to run Convert-MsolDomainToStandard, and then force a re-sync of our password with Azure AD Sync. All good so far.
First question. What powershell can we run to confirm that all our passwords are re-syncing OK on the Azure/365 side? For example, can we get the last password sync time for each user? (not last password change time - that's different!) We really need confidence to pull the trigger on this with 18,000 users.
Second question. After we run this, what powershell can we run to ensure all users have been de-federated properly? A belts and braces check that they've all been correctly updated. I've seen that a lot of people de-federating have had to use Convert-MsolFederatedUser for some users after Convert-MsolDomainToStandard crashed out. What attributes would mark an Azure user as using federated logon rather than managed?
You can review the Application Event log to check if the password sync for every federated user is successful, as well as the sync time.
The Event ID 650 indicates that the password sync process started, and the Event ID 657 will show you users whose password sync is successful or not.
For the second question, I haven't found such powershell comlet to query if the users have been de-federated or not. However, when using the following cmdlet, you will get the users listed in the password.txt, which contains each federated users' temporary password. If you run the following cmdlet again, the users who have already been converted to de-federated will not be issued a new password, the temporary password column will be changed to N/A after the full password sync is completed. So, you can confirm if a user is de-federated or not based on this by examining the password files.
Convert-MsolDomainToStandard -DomainName federated Domain name -SkipUserConversion $false -PasswordFile c:\password.txt
Finally, more references around this can be found here:[1] and [2].

How to use Microsoft (not Organizational) account with Add-AzureAccount?

I'm trying to use the Add-AzureAccount command that's part of the Azure PowerShell tools (August 2014, v0.8.6), and although various examples on the web lead me to expect that it will let me use either an organizational account or a Microsoft Account to log in, in practice, it seems to be requiring an organizational account.
When I execute the command, it opens a hosted browser window as expected, but the prompt says Sign in with your organizational account followed by a username and password. There seems to be no way to tell it that no, I actually need to use a Microsoft Account.
(As it happens, my email address is associated with both an organizational account, and also a Microsoft Account. This may not be helping.)
I could create a completely separate organizational account in an Azure Active Directory, make that a co-admin, and log in with that, but it seems like this shouldn't be necessary.
Is there some way to force it to offer me both options?
I was able to resolve this problem through trial-and-error. As Paul points out in his post, you can load your subscription info into PowerShell using the following sequence:
1. Get-AzurePublishSettingsFile
This will open a browser to a special page that lets you download your profile settings file.
Note: If you have multiple subscriptions, you must use the dropdown to select the one that contains the Azure components you want to manage. For instance, I have a BizSpark subscription that I use for my own company, and a separate MSDN subscription that my clients use (adding me as an administrator). Both subscriptions show up on my management portal page, so I needed to download 2 separate publishsettings files.
2. Import-AzurePublishSettingsFile my-subscription.publishsettings
In my case, I renamed the settings files to "BizSpark.publishsettings" and "MSDN.publishsettings", so I ran this command twice.
3. Get-AzureSubscription
This will list all of the subscriptions that have been imported into PowerShell, showing the subscription name and the other properties.
4. Select-AzureSubscription -SubscriptionName "my-subscription"
You can now use the subscription name to select the subscription you want to use. This allows you to switch back and forth between subscriptions and work with the Azure components you need to manage.
Use #outlook.com instead of the organizational address and you will be directed to the Microsoft Account login.
Azure can be signed up with either Microsoft Account or Organizational Account. Add-AzureAccount will display a message like "Sign in with your organizational account" in the browser window, but actually if you input your Microsoft Account email address into the box and move focus out, the page will redirect to Microsoft Account sign page automatically, and then you can sign in.
Sometimes you may meet some error like "The cache contains multiple tokens satisfying the requirements". You can try to clean all the existing Azure Accounts firstly and then try to sign in again.
To clean up, run Get-AzureAccount | Remove-AzureAccount.
I have a similar problem. Using Add-AzureAccount with my Microsoft Account result in adding my organizational account.
For example I run Add-AzureAccount, in the form I type davideicardi#hotmail.com (my Microsoft account) but the resulted account is davide.icardi#mycompany.com (my organizational account).
I solved by deleting all the Azure account registered on Power Shell (also the one not related to my account, using Remove-AzureAccount), then I have deleted IE cookies (not sure it this is important...), closed the powershell console and executing again Add-AzureAccount.
I suspect that there is a bug somewhere...

user account "effective permissions" with powershell

I need to compare AD users permissions (one user can "unset" an attribute and another cannot, both can change it).
How can I dump/compare user account "effective permissions" which I find when I go to user account > Security > Advanced > Effective Permissions (and select an user account) with powershell?
Using Quest Free PowerShell Commands for Active Directory is simple:
Get-QadPermission useraccountname -Inherited
or better way:
Get-QADUser -Name useraccountname -SecurityMask DACL | Get-QADPermission -Inherited -SchemaDefault
This return all effective permission Inherited or Explicit assigned for the user 'useraccountname'
The comparison can be made with compare-object.
A very simple example:
compare-object (Get-QADPermission userA -Inherited | select Rights) (Get-QADPermission userB -Inherited | select rights)
We were in a similar situation once and needed to know who all could delete one of our main OUs, so we figured that maybe we should dump the ACL on the OU and look for everyone who had delete permissions on the object. Of course dsacls was very helpful in this regard and we could dump the ACL on it easily.
But then, as we started looking at the ACL, we found that it had almost 60 permission entries, including about half a dozen deny entries, some of which were direct and others inherited. We initially didn't consider the denies and came up with a list of about 200 users who could delete the OU, but that did not seem right (; it seemed too high.) Then, we realized that we had to intersect the denies with the allows!
So we flattened all deny permissions, and all allow permissions, but then we had to figure out which of these denies would apply, since some of them were inherited, and I believe the inherited ones don't negate any direct allows, so that took some more pain-staking work, and while doing it we realized that some of those inherited permissions did not apply to the object, so we had to start from scratch!
Finally, we almost gave up, and when I asked one of our Enterprise Admins, he said what we needed to do was determine Effective Permissions on our OU, and he pointed us to the Effective Permissions Tab in the Active Directory Users and Computers snap-in.
So we launched ADUC and navigated to the Effective Permissions Tab, and figured it would be a matter of clicking OK somewhere. However, we soon realized that it needed us to enter each person's name individually. Now, we have almost 2000 people in our environment, so there was no way we could put in 2000 people's names one by one. The other thing was that even for a single person, it would show us all the effective permissions for that person, and in technical terms, which we would have to further refine.
We then figured we'd give Powershell a shot, and looked at many options to do this using Powerhsell, but there was no easy to determine effective permissions in AD using Powershell, which was disappointing. In particular, we tried Quest's free PowerShell commands Get-QadPermission useraccountname and Get-QADUser -Name useraccountname, but we were disappointed to see that this only retrieved the list of all permissions specified for a given user. It did not reveal the Effective Permissions granted to a user. We found ourselves having to start with the results it brought back to then manually try and determine effective permissions, which was not worth our time.
So, we had almost given up hope, but before quitting we thought we would just Google "Active Directory Effective Permissions Tool" with the hope that there must be something out there that could do this for us. I am glad we did because we found a tool that could do exactly what we needed: figure out effective permissions on our OU and give us the ability to export these effective permissions -
http://www.paramountdefenses.com/goldfinger_capabilities_true_effective_permissions_for_active_directory.html
We found that this tool (called Gold Finger for AD) has the ability to determine Effective Permissions on Active Directory objects, and provide the output such that we could easily see the list of all users who had "effective permissions" for a specific right on an object. For instance, we were able to use it to determine and enumerate the list of all admins who had "effective delete access" rights on the OU we were interested in.
It has turned out to be quite helpful for us, and maybe it could be of help to you too. I just thought I would share this because I've been the dsacls route and I wouldn't want you to go through the same pain we did in trying to manually do this. Its just too painful to do do manually.