I've created a Chrome extension and I'm trying to use managed settings. My policy from ExtensionSettings shows up in chrome://policy and when I show value, it has the correctly processed compact JSON which I have formatted like:
{"myextensionid":{"setting1":"value", "setting2":"value"}}
This shows up in the Chrome policies section of the chrome://policy page with a status of Schema validation error at "(ROOT)": Unknown property: setting1
When I check the checkbox for Show policies with no value set and scroll past all the Chrome policies, I can see a section for with my extension's name and ID. All of the schema values that I supplied in my schema.json file referenced in the manifest are listed (thus my manifest and schema within the extension seem fine) are listed with a status of Not set.
Since the documentation on this is awful, does anyone have advice on how to properly set the managed policy values for my extension using group policy? I'm able to configure the policy values using the registry like Configuring Apps and Extensions by Policy covers, but it mentions being able to set those with GPO. I've installed the Policy Templates for Chrome but there doesn't seem to be any policy that lets me set 3rd party extension policies.
Related
I am struggling to create and configure an Azure Enterprise Application.
I have been trying to accomplish this task via PowerShell. I attempted to create an enterprise application by making use of the tags an application registration can have by following this github post, which essentially boils down to adding this tag to the service principal:
$tags = #("WindowsAzureActiveDirectoryIntegratedApp")
From there, I seem to be having problems with adding an identifier uri to the application. Here is the error:
Values of identifierUris property must use a verified domain of the organization or its subdomain
This error does occur to me whether I try this using PowerShell or Terraform.
I think it might be possible to resolve this error by adding the url as a custom domain, but the weird thing is that this url is used by the enterprise application that is setup manually, so I'm a little confused by this error and think the problem might be more than just adding the url as a custom domain.
I would like to note that at this point if I remove the identifierUris the application registration and service principal are both created, but if I were to go to SAML section of the service principal, there does not seem to be a way to manually upload a SAML metadata file (via PowerShell only - it does work in Terraform, interestingly enough).
This brings me to the other issue that I face for configuration: SSO configuration, specifically via SAML. I would like to programmatically upload a SAML metadata file and then modify some of the fields in the SAML section of the service principal from the result of that upload. However, I have been unable to find a way to do this or find an equivalent workaround.
EDIT: Turns out you can upload a token certificate to the service principal via Terraform - for more info on the command see here. You will need to transform your data into an accepted value format (I would recommend .pem if you are coming from a .xml file). I am not 100% sure if this command works yet, as I am left with this message under the SAML Certificates section:
**Token signing certificate**
A certificate has been successfully created. Please reload the page to make it active.
And reload doesn't seem to be working yet...
Issues still left to address:
Identifier uri (previously mentioned)
How to edit the Attributes & Claims fields
EDIT 2:
So I was able to uncover this resource, which offers a step by step guide for automating away SAML-based single sign-on via MS Graph.
Still testing it - and there are some parts that can only be done on Windows (creating a custom certificate) - but this seems very helpful.
Based on my early testing, the only problem I have found with this method so far tis that might not edit the Attributes and Claims section of SAML SSO. However, I believe by creating your own application template this method solves the identifier issue I was running into.
So, the MsGraph tutorial largely covers most of what I needed for my usecase. A few things of difference that I would note:
I used a template application that suited my needs better*.
Attributes and claims are fixed by following the tutorials points on creating and assigning a claims mapping policy. You will not be able to see this through the GUI. Additionally, getting the updated service principal also does not display this configuration**.
If you have difficulty updating your logoutUrl I would see this github post - you can configure it via az rest, PATCH, and this endpoint: "https://graph.microsoft.com/v1.0/applications/$($app_id)".
Tying it all together is a little annoying via PowerShell as it seems that some of the commands take longer to process than others. As a result, I would recommend implementing some sort of retry into your script and even calling Start-Sleep so that future cmdlets recognize resources created by the ones that have already been called.
*Note the process of finding a template that works best for you can be a bit tricky if you do not already have one in mind. I ended up selecting the template that matched the enterprise application I was using when doing this process manually. I am unsure if every enterprise application available has a template that matches it.
**The only way to get a confirmation that a new claims mapping policy worked is to see this message (under the Edit section of Attributes & Claims, which is in the SSO section of the service principal): "This configuration was overwritten by a claims mapping policy created via Graph/PowerShell. Learn More.".
Trying to add an additional claim to our custom Sign In page on Azure ADB2C (using custom policies) to hold a captcha response token. But the custom policy won't render the element on the page.
I've tried the sample here:
https://github.com/jasjeetsuri/B2C-IEF-Custom-Policies/tree/master/LocalAccounts%20-%20Captcha%20Integration
But the additional field doesn't get rendered on the UI. Everything else is working, the captcha appears on the UI and when I log in I can see my validation API being called with the default value 0. I just can't get a DOM element to be rendered by the policy so I can set the response token.
I've tried:
Adding a custom User Attribute (e.g. captcha) and referring to it as extension_captcha
Updating the ContentDefinition to the latest
Using with the Required attribute set to True, this actually gave me an error message to say the value was missing however the field was never rendered on the page
Changing the CombinedSignInAndSignUp to ClaimsExchange but this reverted the custom Sign In UI back to the Microsoft default layout
I've gone through documentation here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-user-input?pivots=b2c-custom-policy
and here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/user-flow-custom-attributes?pivots=b2c-custom-policy
But no luck.
Does anyone know what the minimum config is to get this working?
I made the sample this way because it doesn’t work for combined sign in and sign up page. You would need two seperate policies and deep link between them.
I have a custom policy which adds a custom value, HoldingId, to new users who sign up (using these docs) as the value is passed to the policy via the token (along with verified_email).
I was hoping to not need to create a custom policy for sign in, so used the Azure Portal UI to create the custom attribute against the b2c-extensions-app application (and am using the respective client and object ids to line it up with the custom policy), and using the Portal have added this custom attribute to the sign up/sign in policy claims.
Using the Graph API, I have been able to successfully confirm that the custom value is saving against newly signed up users (returning as extension_[AppId]_HoldingId), and these new users are able to sign in subsequently without issue using the built in sign in/sign up policy.
However, any users which already existed in the directory are no longer able to sign in. Unfortunately, because it's a built-in policy, I'm not sure of a way to dig into the logs a-la App Insights to see what's going on.
My suspicion is that because these existing users don't have this custom attribute against them, the built-in sign up/sign in policy is attempting to get this value and failing.
Is it possible to get the built-in policies to ignore this attribute on users who don't have this attribute set, or will I need to create a custom policy to handle this scenario with a default value?
For context, the HoldingId is not required for existing users (application needs to be backwards compatible). This is also my first venture into B2C, so I'm still learning many of these concepts.
I'm passing in custom attributes via JWT to my sign-up policies but the attributes are not persisting/saving.
I've verified I'm sending the values in the JWT.
I've temporarily displayed the values on the signup page and I'm seeing them.
I've verified the Technical Profile that saves the custom attributes to AD.
What else can I check?
It turns out, I renamed the attribute, extension_helloWorld to extension_HelloWorld, and that use-case is not supported. Apparently, you can't just change the casing of a custom attribute.
I had to delete the custom attribute and then it started saving! FYI, I used the Graph Explorer to delete the attribute.
I am trying to generate a http cookie for succesfull user login in openam.
The cookie is expected to be populated with a ldap attribute name 'commerce' which is a boolean attribute.
In order to achieve this I have done settings under --
access control --top level realm --agent -- configured policy agent --Profile Attributes Processing
Over here I have created a map with key as commerce and value of commerce, now ideally after a succesfull login it should generate a cookie with name --HTTP_COMMERCE with value of attribute, but this is not working as expected.
Can some one help me out in resolving what I may be missing over here.
When using Profile Attributes Processing it is probably important to know that the attributes are retrieved from the configured data stores, hence you should probably make sure that the data store has correctly configured in OpenAM.
Most likely you are just missing the "commerce" attribute from the "LDAP User Attributes" setting.