I am working on a PowerShell script that very often produces the same, irrelevant warnings. This warning pollutes the script output, and I want to get rid of it. However, I don't think it is a good practice to omit all warning, so I was wondering if it would be possible to omit very specific warnings?
In my case, I want to remove the following warnings:
WARNING: TenantId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' contains more
than one active subscription. First one will be selected for further
use. To select another subscription, use Set-AzContext.
WARNING: Unable to acquire token for tenant
'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx' with error 'You must use
multi-factor authentication to access tenant
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, please rerun 'Connect-AzAccount'
with additional parameter '-TenantId
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'.'
Any idea how can this be achieved?
First I'd recommend that you use the most recent version of Az.Accounts to ensure that you are not facing any knowns issues (currently version 2.5.2).
When running Connect-AzAccount we populate the local context based on the first 25 subscriptions returned. It seems that one of those requires MFA therefore cannot get a token.
To avoid the warning, try to be specific of the subscription/tenant that you want to use.
Related
I am trying to use System Assigned Managed Identities with my Azure Function App. I do not want to do local debugging, just run the function through an API call. According to the documentation, if I wanted to do local debugging, I could set
AZURE_TENANT_ID
AZURE_CLIENT_SECRET
AZURE_CLIENT_ID
and then the function app would like for these in my local environment when doing local debugging, but as I said I am not doing local debugging (hitting endpoint through postman by way of API Management) so those ENV vars should not be included.
My confusion comes because when I remove them, I receive the following error:
EnvironmentCredential authentication unavailable. Environment variables are not fully configured. See the troubleshooting guide for more information. https://aka.ms/azsdk/net/identity/environmentcredential/troubleshoot
And the horrible irony of this error message is that it seems to be telling me that I need to set those ENV variables, even though I should not need to.
I must be mixing something up here, can someone see where my mistake is?
FYI - I am not a C# developer, so if you were going to require those ENV variables I listed above, where would you do that in the code? I'm wondering if they set things to always do local somehow, so it's requiring them.
I realized my issue. I hadn't realized that one of the developers had added EnvironmentCredential() to the code, so it was always looking for the AZURE_CLIENT_ID, which is what broke things when removing the AZURE_CLIENT_ID.
The reason they added it was understandable though, they need to access a b2c tenant account's graph API and as of right now I am not sure how to give that permission through a MI instead of an App Registration, so for us it seems managed identities won't work well sadly. We did not want to tightly couple config and code by requiring a large number of ENV variables to gain access to various services, but it seems like we would need to do that to make things work. We also were running into local testing issues with eventgrid and System Assigned MI because it seems locally the user who is an owner of the subscription, is not able to write to eventgrid topics and we weren't able to find a way around that which seemed clean
In my case, I had a similar error and I was searching in the wrong direction.
I only changed DefaultAzureCredintials to AzureCliCredintials.
from azure.identity import DefaultAzureCredential
Replaced with:
from azure.identity import AzureCliCredential
Then it was solved.
source ;github azure-identity
I'm trying to access user's presence off of https://learn.microsoft.com/en-us/graph/api/presence-get?view=graph-rest-1.0&tabs=http
I've granted my AD app Presence.ReadWrite.All which is described as "Allows the app to read all presence information and write activity and availability of all users in the directory without a signed-in user. Presence information includes activity, availability, status note, calendar out-of-office message, time zone and location.
".
There seems to be a bit of a conflict between the docs and what the permission's name is - the docs seem to imply it doesn't work with an application scope, while the permission name/description seems to say it does.
The error i'm getting is Forbidden. This seems to be different from accessing a resource with insufficient permissions (which straight up says InsufficientPermissions).
The docs are clear that you can't do this with Application scope. That means even if the particular permission seems like it should work, it might be because it's used in that way for another endpoint. Notice that, for instance setPresence and clearPresence both support Presence.ReadWrite.All.
What's really crazy though is that neither getPresence (your endpoint) nor (get Presence for Multiple Users)[https://learn.microsoft.com/en-us/graph/api/cloudcommunications-getpresencesbyuserid?view=graph-rest-1.0&tabs=http] support Presence.*Read*Write.All - there is no supported read scenario!
From what I can see, your best bet is to keep an eye on this request and to upvote it. Microsoft (Darrel Miller) is quite active there from last year - perhaps there's an update coming.
I am trying to setup a simple RPA application through BluePrism which will login into a website and will perform certain tasks. Now, while logging into the website through BluePrism I am getting Authentication error although the password and username is correct.
Normally, I can login but error is showing while logging through BluePrism. Can anyone please tell why this is happening?
There are two options for passing credentials (Username & Password)
1. Hard Coded - If you are using hard coded values, please check if values are correct. Sometimes space or any special characters can lead us to error.
2. Credential Manager - If you are passing credentials through credential manager make sure you are using correct variables mapping so that there is no mismatch.
3. Lastly make sure you are using wait stage so that while executing the application it is waiting for values to be pasted or passed before control moving to other screen or other function.
Please check caps lock key of keyboard, when running the process.
We have a worker role in Azure which uses Process.Start to kick off a background process (which hosts a native application we need to run)
FxCop gives me a whole load of CA2122 errors due to a link demand. When I tried to add this attribute:
[PermissionSet(SecurityAction.LinkDemand, Name = "FullTrust")]
I then started to get CA2135 instead, the solution to which seems to be to add the SecurityCritical attribute instead.
But then I get the CA2122 again.
Are either of these things an issue? Under what circumstances could they be and how can I be sure that I'm not introducing a security problem?
SecurityCritical should perform an equivalent role as a LinkDemand for full trust:
The SecurityCriticalAttribute is equivalent to a link demand for full
trust. A type or member marked with the SecurityCriticalAttribute can
be called only by fully trusted code; it does not have to demand
specific permissions. It cannot be called by partially trusted code.
Ergo, I'd suggest adding SecurityCritical (to fulfil the needs for CA2135) and suppress the CA2122, which is presumably just Microsoft forgetting to account for their newer solution in their code analysis.
The objective of CA2122 is to ensure that the method...
no longer provides unsecured access to the link demand-protected
member.
This isn't the case once SecurityCritical is added (which ensures the member can be called only by fully trusted code), so the second CA2122 is a false positive.
I'm calling the Advapi32.dll LsaEnumerateAccountRights function having a policy handle from LsaOpenPolicy and an account SID from LookupAccountName.
However, try as I might, I'm always getting back 0xC0000034 which after translation by LsaNtStatusToWinError gives me "The file referenced cannot be found."
Which isn't a whole lot of good. My code handles this and goes on to grant the account SID the SeServiceLogonRight using LsaAddAccountRights, so I know that the policy handle and the account SID are fine as that would bomb out if something was wrong with one of those.
The end result is that the account does have the right it needs so overall the code works.
However, I'm using this within an MSI custom action, the Install checks to see if the account has the right and if it doesn't (or it fails as above) it grants the right and remembers it has done it in the install state. If a rollback happens and it added the right it then removes it. We never remove in an uninstall as other applications may have been installed using the same domain account that the services we run use.
So the problem is when an MSI performs a rollback - it will always remove the right as it always thinks it has added it. So checking the rights using LsaEnumerateAccountRights is used for this - but I just can't get it to work.
Any idea - please note that I'm using c# with DllImport attribute to expose the Win32 functions, and I'm not the worlds best Win32 programmer having been Unix before C#!
I have been struggling with this, too, but have just cracked it...
Retrospectively, I now see there was a clue in the msdn documentation:
"The accounts returned by this function hold the specified privilege directly through the user account, not as part of membership to a group."
See: link text
Get the policy handle from LsaOpenPolicy() and an account SID from LookupAccountName() exactly as you said.
If the username you entered was the name of a group ("Users", "Administrators", etc) then LsaEnumerateAccountRights() works fine and enumerates all the rights for the group.
If you call it on a username whose rights derive solely from the groups of which it is a member, then it returns 0xc0000034 (= Windows error 2 - The system cannot find the "file" specified), meaning (we now realise) "cannot find any individually assigned additional rights". It seems that the Windows Error 2 translation is a catch-all for "what you were looking for has not been found".
Now...
If you have ntrights.exe, run it... for example:
ntrights +r SeNetworkLogonRight -u MyUserName
Then, LsaEnumerateAccountRights() works fine, returns without error and enumerates a single right, "SeNetworkLogonRight".
I have recently run up against this same problem. In my testing with this issue it appears that the LookupAccountName call returns a security principal rather than the full SID. The actual failure seems to be that the section within the SID where the user rights would be is either not there or shortened to only the logon right.
Performing a LookupAccountName call on the current logged in user and then trying to LsaEnumerateAccountRights against that SID results in only the user logon right. Even though clearly, there are many other rights attached. Trying to retrieve any other users, other than the logged on user, successfully returns a SID. However, that SID will not have any user rights in it.
I have tested this on no domain workgroup systems and member systems of domains both as admin and regular users. The LookupAccountName call when successful, always results a SID that does not contain the full set of user rights.
I can only assume that if a complete SID could be obtained from the Security Database, then the LookupAccountName would properly iterate the rights.
I too have the exact same problem. Somebody suggested I get the SID via WMI with this query:
SELECT * FROM Win32_Account WHERE domain = 'ntdomain' AND name = 'username'
I tried it, using ConvertStringSidToSid() to get the magic blob LsaEnumerateAccountRights() expects and... same error. "The system cannot find the file specified."
I meet the same problem, it is because you dont assign spefic privledge to the user, so the user priveldge is empty, if you add one to it, it wont fail.
Call the same function with a group you can see everything working correctly.