I am trying to add AAD app in Key vault Access Policy.
AAD app gets added successfully, but it overrides the existing resources in Access Policy.
Deployment Mode is set as Incremental, but still facing this issue.
What am I missing?
It overwrites the access policy array always, so make sure to include all of the users/groups/apps you want in the ARM template itself, and do not modify access policies from the portal.
Setting AccessPolicy always overrides the existing policies...
But you can add an entry to the AccessPolicy in ARM; see: https://github.com/Azure/azure-quickstart-templates/blob/master/101-keyvault-add-access-policy/azuredeploy.json
Also there is a workaround by first reading the existing policies and then add the one you need.
See also: https://toonvanhoutte.wordpress.com/2018/11/13/key-vault-deployment-removes-access-policies/
Also there is a feature request, that AccessPolicy should also support incremental updates: https://feedback.azure.com/forums/906355-azure-key-vault/suggestions/34414747-arm-template-for-keyvault-to-have-accesspolicies-n
Related
I have an Hybrid AD and AAD enviroment. We use AzureAD to provision users and attributes to one of our SaaS solutions. One for those is the "manager" attribute. The problem is that once the manager value has been set once, it does not update. And since the users are synced from onprem, the manager field is in "read only"-mode and there is no way for me to update it.
When i change the value on one of my users and run a sync to AzureAD i can see that there are 1 change to the export attribute flow and Updates to the Delta Import. But in AAD the old value persists.
I ran the Sync troubleshooter and checked for sync issues in AAD, but there are no indicated errors. Everything else seems to work and sync as intended. Anyone know if there is anything special with "manager"? Any help would be appritiated.
As you know Salesforce is enforcing Enhanced Domains. I found from Salesforce help that:
Custom components in your org must be evaluated in order to check
whether they use domain name/static URLs
Some embedded content stored in Salesforce might no longer appear
Third-party applications can lose access to your data
Single sign-on integrations can fail
However, I'm struggling with finding out which particular Salesforce elements/configurations should be checked in order to detect potential gaps? Do you know which areas exactly can be affected and shall be evaluated (like Apex Codes, Email Templates and so on)? Is there any guide on that?
Your biggest concern should be inbound integrations. Things that log in over REST/SOAP API, get response with session id back, ignore the "url to use for all subsequent requests" and just use hardcoded url, whether it's prod or sandbox.
Look at this guy, he's victim of either enhanced domain or "disable api versions < 30" thing: The requested resource no longer exists with rest PHP. Look at these guys, they had hardcoded url: how to solve python code error (TooManyRedirects: Exceeded 30 redirects), Salesforce API via postman error INVALID_SESSION_ID.
As for stuff inside Salesforce itself - best would be to download whole project with sfdx and run a text search for your domain name (and site/community name if you have these). Email templates that use merge fields for forgot password etc should be fine, merge fields with record link should be fine... But if you manually craft email body in apex - might be a problem. A lot depends how creative the developer was. If you find getsalesforcebaseurl().toexternalform() it should still work. If it's hardcoded / read from custom setting / custom label / custom metadata it might be more fun.
If you have external apps that display pieces of salesforce (embedded live chat? some iframe with FAQ? CMS Connect) - the domain change might mean they need to be updated, both in terms of updating url and changing security rules (CSP for example)
Currently we have an application in production that allows for Single sign-on in tabs, we followed https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso and this works well.
For this to work an Application ID URI is set, like so: api://www.domainusedintab.com/378271d1-b8e4-4f01-a9bb-e724dbec43c8, where 378271d1-b8e4-4f01-a9bb-e724dbec43c8 is some application ID.
We now want to add Single sign-on support for bots, like described in https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/authentication/auth-aad-sso-bots. To make this work a change is needed to the Application ID URI, api://botid-5d417275-b104-462e-9998-2b2b0ec4244f, where 5d417275-b104-462e-9998-2b2b0ec4244f is the ID of the bot service.
The problem is that it's not clear on how to combines these two into a single Application ID URI, based on the previous documentation pages it seems it's one way or the other.
We tried to just tack on /botid-5d417275-b104-462e-9998-2b2b0ec4244f after our current Application ID URI, to make api://www.domainusedintab.com/378271d1-b8e4-4f01-a9bb-e724dbec43c8/botid-5d417275-b104-462e-9998-2b2b0ec4244f. This seems to work fine... But it also seems like a bit of a hack that might break at any time.
Are there any resources on how to properly solve this?
We can add the existing bots to the existing application to work on SSO. We need to add the web applcation info in the manifest to view the changes in the application. For more information please check Single sign-on (SSO) support for bots
As it turns out, it is possible to provide multiple Application ID URIs for an App registration. This is not available through the Expose an API interface, you need to change it directly in the manifest. The identifierUris field holds the Application ID URIs — the current one from the Expose an API interface should be the only item here.
A follow up on my earlier question - Are there any APIs available to manage conditional access policies for a tenant?
I'm using the API (https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/policy_list) to retrieve the list of policies created for my tenant and have been running into permissions issues.
According to the documentation this API requires a scope of Directory.AccessAsUser.All. On the Azure AD portal, I set the permissions for my test App to include "Read and write directory data" and "Access the directory as a signed-in user". I set these permissions on both Windows Azure Active Directory and Microsoft Graph APIs. When I make a call to https://graph.microsoft.com/beta/policies, I keep getting 403 Forbidden with the error message "Insufficient privileges to complete the operation.". The other operations like getting the users in the directory, getting identityRiskEvents, etc all work fine.
Am I missing anything here?
Thanks in advance!
Actually the answer is no. The GRAPH REST API List Policies does not return conditional access policies yet.
The REST API doc states:
Currently only one type of policy is available:
Token Lifetime Policy - Specifies the lifetime duration of tokens
issued for applications and service principals.
Check the microsoft faq documentation on configuring conditional access.
Are Graph APIs available for configuring conditional access policies?
Currently, no.
FAQ Link
No, There is a REST API List policies of Operations on policy described in Graph API reference, which you can use it to list all policies for your tenant.
Edit: This article lists only Token Policy's are being returned at this moment: https://learn.microsoft.com/nl-nl/graph/api/resources/policy?view=graph-rest-beta
Microsoft have recently released access to conditional access policies in their Graph API beta (https://learn.microsoft.com/en-gb/graph/api/resources/conditionalaccesspolicy?view=graph-rest-beta). The current methods they support for the conditional access policy resource type are:
List
Create
Get
Update
Delete
Similar methods are available for named locations included in a policy.
For the CQ5 environment I work on we have a farm of publisher servers. Some of the content on these servers is restricted so only users who belong to certain groups can see the content. I'd like to script the setting of permissions for the folders (nodes) that are to be secured so I don't have to manually repeat the steps of applying security using the Access Control Editor of Content Explorer (This Adobe documentation has instructions for doing it manually via Access Control Editor). The scenario is that sometimes new folders are to be created to hold secure pages, and we want to apply permissions to the folders prior to activating any content into those folders.
Since the environment has several publishers, it is repetitive, manual, and error-prone work to open Content Explorer and set the permissions on each one. I'd like to do be able to automate this so I could roll out permissions to all the servers via a script--perhaps via a curl command or some other mechanism (perhaps a package?) that can be automated.
I found the Sling jackrabbit-accessmanager bundle that seems like it will facilitate automation of this, but it seems like it opens a security hole. If I put this bundle on my publishers, it seems like I would be providing an REST interface to let anyone modify the permissions and grant access to folders/nodes that should be secured or to add security restrictions on nodes that should have none.
How can I automate the creation/modification of node permissions via a script--and do so in a way that only allows an administrator to apply the permissions changes?
This tool lets you manage permissions in a centralised way, they can also be installed automatically at deploy time:
https://github.com/Netcentric/accesscontroltool
Regarding permissions applied to new folders, the solution is setting permission properly on their parent folder. CQ/AEM will automatically apply the same permissions to all children unless another rule break the inheritance.
I found one alternative I hadn't considered before: using the Day CQ ACL Setup Service. It is mentioned at http://dev.day.com/docs/en/cq/5-5/developing/security_model_changes.html.
AclSetupService allows one to add permission to a single path or a given user/group. This will be applied on each restart of CQ to guaranteed a certain permission state within CQ. For example, "allow;inherit;everyone;/" prevent everyone from accessing CQ (i.e. it forces all users to login first). As noted in the description of AclSetupService, you will need the following pattern per entry:
( "allow" | "deny" ) ";" ( privileges | "inherit" ) ";" principal ";" path
Choose either "allow" or "deny" for the first part.
Next enter one of the privilege below or set it to inherit permission from ancestor.
Then enter a single user/group.
Finally enter a single path to apply the permission to.
Using this will replace permission set within the repository when you restart CQ. These could be scripted by using the process outlined here and here.
Privileges can be:
jcr:read
rep:write
jcr:all
crx:replicate
imp:setComplete
jcr:addChildNodes
jcr:lifecycleManagement
jcr:lockManagement
jcr:modifyAccessControl
jcr:modifyProperties
jcr:namespaceManagement
jcr:nodeTypeDefinitionManagement
jcr:nodeTypeManagement
jcr:readAccessControl
jcr:removeChildNodes
jcr:removeNode
jcr:retentionManagement
jcr:versionManagement
jcr:workspaceManagement
jcr:write
rep:privilegeManagement
If you would like to use the Sling jackrabbit-accessmanager bundle on a publish instance it is possible. You would want to make sure your dispatcher which sits in front of the publish instance does not allow the permission requests (/.modifyAce., .deleteAce., etc) and the publish instances can only be accessed directly from inside your network. It's standard practice to deny all requests in the dispatcher and specify what is allowed.
Is there are reason you are not just replicating the permissions when the folder is activated? There should be a rep:policy node underneath the secure folder which gets replicated.