Is there a pendant in the Azure CLI world for the following command?
New-AzureADServiceAppRoleAssignment -ObjectId $clientManagedIdentityObjectId -Id $serverAppRoleId -ResourceId $serverEnterpriseAppObjectId -PrincipalId $clientManagedIdentityObjectId
I'd like to add a managed identity to an appRole within an Enterprise Application.
az ad app permission add does not seem to do the right thing or I am misinterpreting the underdocumented parameters.
There is no built-in cli command to do this, your option is to use az rest call the Microsoft Graph - Grant an appRoleAssignment to a service principal directly.
First, store a .json file as below to your powershell execute location, the meaning of the values see this. e.g. my location is PS C:\Users\joyw>, I store the file in C:\Users\joyw folder.
{
"principalId": "principalId-value",
"resourceId": "resourceId-value",
"appRoleId": "appRoleId-value"
}
Then run the command
az rest --method POST --uri "https://graph.microsoft.com/v1.0/servicePrincipals/{object-id of your Managed identity}/appRoleAssignments" --headers 'Content-Type=application/json' --body `#body.json
Related
I'm trying to setup just for CouchDB, so I can use my current API tokens to authenticate in CouchDB.
But the docs don't seem to provide enough information to set this up.
I don't understand what the payload of the gut needs to contain identifying the user. How do I configure the jwt secret?
Is there any simple example out there or something like or tutorial to do this correctly?
this thread may be helpful:
https://github.com/apache/couchdb/discussions/2947
edit:
ok i found a configuration that worked for me - this solution won't be suitable for anything more than a testing couchdb instance.
configure local.ini (docker image)
1.1 -> ssh to your docker docker exec -it bash
1.2 -> install vim for convenience and disable visual mode:
$ apt-get update
$ apt-get install vim
$ echo "set mouse-=a" >> ~/.vimrc
1.3 -> update local.ini
$ vi /opt/couchdb/etc/local.ini
in [chttpd] section add line
authentication_handlers = {chttpd_auth, jwt_authentication_handler}, {chttpd_auth, cookie_authentication_handler}, {chttpd_auth, default_authentication_handler}
at the very end of the file add jwt_keys config
[jwt_keys]
hmac:_default = aGVsbG8=
hmac:foo = aGVsbG8y
restart your container
configure postman :
bearer token for _default hmac is
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyXzEiLCJleHAiOjE1OTI2MTEyMDB9.Y9jNgSeSBl54V2MHg1hXhivyZsdXTeiAVJR2DSlF6LQ
put it into postman and issue following get request:
http://localhost:5984/_session
you should see something like :
{"ok":true,"userCtx":{"name":"user_1","roles":[]},"info":{"authentication_handlers":["jwt","cookie","default"],"authenticated":"jwt"}}
now go in your browser to couchdb ui and login as admin
http://127.0.0.1:5984/_utils/#login
then click the "lock" icon next to the database you wish the user_1 to have privileges and update the permissions accordingly.
check
check if your user_1 authenticating via jwt has permissions on the database by issuing appropriate request, for example
http://localhost:5984/campaigns
I have installed koha 20.11 and samba4 AD and Kerberos .
I have tried to connect by the terminal using the below LDAP search query and its working fine,
$ ldapsearch -H ldap://MyIp -x -D "CN=Administrator,CN=Users,DC=domain,DC=in" -w "pass#123" -b "CN=Users,DC=domain,DC=in" sAMAccountName=admin
I want to connect samba AD to koha LDAP.
but I am getting the following error.
LDAP search failed to return object : 00002020: Operation unavailable without authentication at /usr/share/test_koha/lib/C4/Auth_with_ldap.pm line 98.
samba configuration :
[global]
dns forwarder = <myIp>
netbios name = DC1
realm = <DC my domain>
server role = active directory domain controller
workgroup = <DC>
idmap_ldb:use rfc2307 = yes
server services = rpc, nbt, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate, dns, s3fs
#ldap server require strong auth = no
ldap server require strong auth = no
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[netlogon]
path = /var/lib/samba/sysvol/<DC my domain>/scripts
read only = No
koha ldap conf.:
<useldapserver>1</useldapserver><!-- see C4::Auth_with_ldap for extra configs you must add if you want to turn this on -->
<ldapserver id="dc1">
<hostname>ldap://ldap domain</hostname>
<base>CN=Domain Computers,CN=Users,DC=koha,DC=kohaconnect,DC=in</base>
<user>CN=Administrator,CN=Users,DC=koha,DC=kohaconnect,DC=in</user>
<pass>pass#123</pass>
<replicate>1</replicate>
<update>1</update>
<auth_by_bind>1</auth_by_bind>
<update_password>1</update_password>
<principal_name>CN=%s#koha.kohaconnect.in</principal_name>
<mapping>
<userid is="sAMAccountName"></userid>
<password is=""></password>
</mapping>
</ldapserver>
NOTE : we are not using koha`s default command, i.e. koha-common and service memcached.
• You are getting this error because you have not restarted the koha-common service and the Memcached service inherent. You can do so by running the below command and checking if the configuration has correctly been done for you: -
‘ $ service koha-common restart && service memcached restart
$ export PERL5LIB=/usr/share/koha/lib/ && export KOHA_CONF=/etc/koha/sites/library/koha-conf.xml && perl /usr/share/koha/opac/cgi-bin/opac/opac-user.pl userid=user1 password=password ‘
Please ensure to adapt the path to the koha-conf.xml, as well as user and password. Also, please note that you can bind to LDAP as user at REALM or NT4DOM\username. So, try doing that.
Find the below link for reference: -
https://openschoolsolutions.org/koha-ldap-setup/
I'm actually working on the Continuous Delivery pipeline for the UI project made in ReactJs with the use of the Azure Static Web App.
I want to create and deploy the static web app to Azure based on the git repo located in Azure DevOps.
The reason behind this is I see a huge opportunity to create a Pull Request Environment pipeline for the system I work on every day with the usage of static web apps which seem to be a super cheap and fast solution! Then the pipeline would allow testing the Pull Request changes in isolation before releasing to DEV, QA,... Prod environments.
Anyway, straight to the point.
The official Microsoft documentation provides only an example of how to do this for GitHub repo but I cannot find any info on how this can be achieved when using Azure DevOps git repo:
az staticwebapp create \
-n my-first-static-web-app \
-g <RESOURCE_GROUP_NAME> \
-s https://github.com/<YOUR_GITHUB_ACCOUNT_NAME>/my-first-static-web-app \
-l <LOCATION> \
-b main \
--app-artifact-location "build" \
--token <YOUR_GITHUB_PERSONAL_ACCESS_TOKEN>
I thought that the way the az staticwebapp create works in the provided example should be analogical with the Azure DevOps.
I thought that equivalent of YOUR_GITHUB_PERSONAL_ACCESS_TOKEN in Azure DevOps would be an access token that can be generated:
When I try to run the following code:
az staticwebapp create -l westus2 -n appNameTest1 -g TestPrEnvResourceGroup -s "https://dev.azure.com/myOrganisationName/myProjectName/_git/myRepoName -b "main" --token "generatedTokenValuefwfsdgsgsd"
I'm getting the following exception;
Command group 'staticwebapp' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus Operation returned an invalid status 'Bad Request'
Also, I don't think it can matter but the TestPrEnvResourceGroup is created under the UK West location.
It doesn't tell me much, like if the token or some other parameter is wrong...
Any ideas?
Cheers
Have you tried this way?
You need to generate a deployment token from the Azure Static Web App and have it in the YAML
I tried the same for Angular app and it worked pretty well
azure_static_web_apps_api_token: $(deployment_token)
UPDATE : As per the Github issue , currently this is not supported.
We currently don’t support automatically creating Azure DevOps
pipelines. This is the supported path for using Azure DevOps:
https://learn.microsoft.com/en-us/azure/static-web-apps/publish-devops
You can vote for the feature here
I have downloaded the logic app template from one resource group , I have modified the template and that modified template I want to deploy it into the another resource group which I already created resource group along with storage account as well.
Can you please help me out with the Azure CLI command to deploy the local Arm template (Logic app).
you are looking for az group deployment create, example:
az group deployment create -g MyResourceGroup --template-file azuredeploy.json \
--parameters #params.json --parameters https://mysite/params.json --parameters MyValue=This MyArray=#array.json
https://learn.microsoft.com/en-us/cli/azure/group/deployment?view=azure-cli-latest
I deployed logging.v2.sink using Google Cloud Deployment Manager, however the deployment was failed by permission denied.
The problem was also happened in this logsink example of Google Cloud Deployment Manager.
The result is following:
- code: RESOURCE_ERROR
location: /deployments/my-project-id/resources/sink
message:
{
"ResourceType": "logging.v2.sink",
"ResourceErrorCode": "403",
"ResourceErrorMessage": {
"code": 403,
"message": "The\n caller does not have permission",
"status": "PERMISSION_DENIED",
"statusMessage": "Forbidden",
"requestPath": "https://logging.googleapis.com/v2/projects/my-project-id/sinks",
"httpMethod": "POST"
}
}
The deployment was executed by owner role, moreover I can create logging sink using cli.
gcloud installed in local is newest (v217.0.0).
Why does this problem happen?
I misunderstood permissions of cloud deployment manager.
I noticed that the accounts of deploying template and creating resources are different(https://cloud.google.com/deployment-manager/docs/access-control).
When I add the Logging Admin role to the service account, deployment succeeds.
[PROJECT_NUMBER]#cloudservices.gserviceaccount.com
Ran into the same problem. Elaborating the answer above:
Deployment manager uses [PROJECT_NUMBER]#cloudservices.gserviceaccount.com to create resources on your behalf. You can check the policy binding for this service account:
gcloud projects get-iam-policy [PROJECT_NUMBER]
This service account has roles/editor on the project by default, which has the following policies for logging sinks:
- logging.sinks.get
- logging.sinks.list
You can confirm this using this command:
gcloud iam roles describe roles/editor
roles/logging.configWriter has logging.sinks.{list, create, get, update, delete} permissions, so you can add a new policy binding to your project and then retry:
gcloud projects add-iam-policy-binding secstate-gcp-test02 \
--member serviceAccount:[PROJECT_ID]#cloudservices.gserviceaccount.com \
--role roles/logging.configWriter