I created an instance of the SingleSignOn service (SSO) in Bluemix, using
cf create-service
Now, when I try to deploy an app that uses that service, I get the follwing message:
CTJSO0015E The service instance with ID \"xxxxxxxxxx\" in the region \"xxxxx\" must be configured before the operation can be performed. If you are attempting to create a new service and bind it to your application in a single step, your service instance should already be created in your dashboard, but you must configure it before binding it to an application. Configure the service and try binding the application again.
I'd like to do an automated deploy of all of this so my only choice is the command line. I know there are many options and I think I'd go with the database (seems to be the simplest possibility). Google or Facebook login would be ok as well.
How do I configure the service using the command line?
you can see the troubleshooting about SSO here: https://www.ng.bluemix.net/docs/#troubleshoot/SingleSignOn/ts_index.html#sso_troubleshooting
in this case:
If you try to bind an application when you create a service instance, the Add Service task fails with the following error message:
CTJSO0015E The service instance with ID svcinstanceid must be
configured before the operation can be performed.
The Single Sign On service does not support binding an application to an unconfigured service instance. You must complete the service instance creation before you bind an application to it. The service creation succeeds when you leave the application unbound. Then, you have to use UI\dashbord service to configure it.
Related
I've used the process documented here https://github.com/Autodesk-Forge/forge-bim360.project.setup.tool to automate creating a new project HUB. We ask our users to fill a form on Service Now for each new project. My question is: Has anyone had any success linking the Service Now API to Forge? So that the variables that are filled by the end user on the Service Now form are used by Forge to create a new project HUB. Thanks.
I am not familiar with Service Now, but I've created integration with internal system.
Integration depends on what you need.
1.You can create a plugin for Service Now(If it is supports adding plugins) ,and create an app to fill into info that you need to create new project in Bim360(project name,users,etc.)
2.If you need to create a new project based on your info in Service Now,you should take Service Now Api, read all info that you need and then pass it to Autodesk Forge Api to create new project.
I want to do some specific task using sawtooth in combination with ansible. I am using this ansible project https://github.com/hyperledger/sawtooth-ansible. The problem is when I want to run "Configure onchain permissions". The main problem is in configure-onchain-perms role in task Create Transaction Access Policy. Always as a result, I get the time out. Also, I tried to install everything manually, without ansible, but output is the same. The same result is with this simple command sawtooth identity policy create policy_1 "PERMIT_KEY *". Could anyone guide me how to use identity family in right way ?
Is the identity transaction processor, identity-tp running on all nodes?
A quote from:
https://sawtooth.hyperledger.org/docs/core/releases/latest/cli/identity-tp.html
This process is required to apply any changes to on-chain permissions
used by the Sawtooth platform.
There is also an active chat forum for Sawtooth at https://chat.hyperledger.org/channel/sawtooth
Seems each time I try to use an existing share for Cloud Shell, it gives me the annoying error
Error: 400 {"error": "code":"AccountPropertyCannotBeUpdated","message":"The property 'kind'
was specified in the input, but it cannot be updated."}}. I have
tried just creating a Resource Group and then a Storage Account before
hand and then selecting to create a new File share but this too fails.
I wanted to use a single share for storing Cloud Shell img files for
each of the members of my team so we could easily share files.
It seems to be a bad behavior. Please use the standard options for initialize the Cloud Shell and verify your Azure account type.
I am creating an msi-package of a Windows service using Wix. I want to run the service under a regular user account without administrative priviliges. For better security I want to put the files of the service in the personal user folders (such as AppData\Local\Programs\CompanyName... for binaries and AppData\Local\CompanyName... for config and data files) with the appropriate file access permissions for the user. I imagine the following scenario:
Start the msi in the per-machine context.
During the client stage of the installation ask for the user name and password.
During the server stage of the installation:
a) create the user
b) change to its context and install the program files to ProgramFilesFolder and the data files to LocalAppDataFolder
c) change back to the admin context and install and configure the service to be run under the user account
I am stuck at the step 3 b) as from what I've learned I can't change the installation context after switching to the server side of the installation. Please could you advice me on how I could achive my goal described in the first lines. In particular if I have to copy files to another user's personal folders, what would be the most reliable way to get their paths? Or maybe I am wrong and installing a service into a personal user folder is bad practice at all?
I am aware of the presence of the built-in Local Service account but would like to narrow the service context even more.
The local appdata folder is the problem. If you create a user account the user folders aren't created until the user does an interactive login, and even then in some environments it may be redirected via policy. I am unaware of any reason that local data is better (in a security sense) then the ProgramFiles folder, which is write-restricted to administrators. I'd just install the service binaries to ProgramFiles. In the UI you can collect credentials and use them when the service is installed. A problem with using external credentials is that things like Repair and sometimes patching will fail unless you have the credentials available, having saved them somewhere safe, because otherwise the property values you use will be empty on repair. If localservice works then use it.
It normally doesn't matter what privileges a service has because it usually knows what it's doing. It's only an issue if it calls unknown external code that may try to do something bad, or if it gets asked to do random things such as "run this program" or "copy this file" without doing any internal validation or having a whitelist of what it's allowed to do. So it might be useful to know if there's a specific problem you're trying to address or just following good practices.
I don't think you're being overcautious, service isolation is definitely a good goal. If you can require Win7/2008R2 or later, then you can run the service under a virtual account. There is no password required for virtual accounts, and they don't have the ability to completely wreck the machine like SYSTEM does. You should be able to use it like this:
<ServiceInstall Account="NT SERVICE\$(var.ServiceName)" Name="$(var.ServiceName)".../>
It's actually better for the service executables to be in Program Files, that way the service can't modify its own exe.
We use Jenkins and Active Directory plugin for authentication.
For some reason, I need to add a specific account in Jenkins but not in Active Directory.
Is it possible to use both Active Directory and internal user ?
If it's impossible, I think I can modify the plugin to add an account in it.
I know it's not a good idea, but we need this function.
I think it's in ActiveDirectoryAuthenticationProvider.java's retrieveUser() function.
If you have Jenkins deployed to an app server and the app server supports your use case, you can use the "Delegate to servlet container" option in the Security Realm.
You might be able to utilize the Script Security Realm Plugin