I'm deploying an ear to one of my Weblogic servers with CustomRoles security model. From the console it's not a problem to define a new role and to assign it to a group.
However I'm trying to do this from the WLST console with no success. Is there a way to do this with WLST? The deployment/undeployment gives me no problem using the following commands
deploy('app','app.ear','server', securityModel='CustomRoles')
undeploy('app','server')
See the oracle docs
You want to do something like
serverConfig()
auth=cmo.getSecurityConfiguration().getDefaultRealm().lookupAuthenticationProvider("DefaultAuthenticator")
auth.createUser(login, password, login)
auth.addMemberToGroup(group, login)
Related
I am unable to create project in open shift. I created a project previously and deleted it. Looks like a project exists but unable to access or delete it. Seems like i am stuck. Also logging into the console https://console.preview.openshift.com/console/ doesn't show any existing projects.
I ran the following oc commands from the terminal.
Any suggestions on how to resolve this issue?
Thanks
XX:~ XX$ oc new-project test
Error from server: projectrequests "test" is forbidden: user XX cannot create more than 1 project(s).
XX:~ XX$ oc delete project test
Error from server: User "XX" cannot delete projects in project "test"
XX:~ XX$ oc status
Error from server: User "XX" cannot get projects in project "default"
XX:~ XX$ oc get projects
You need to give privileges/policies to your user which will allow the actions you want to perform.
If you are just in a proof-of-concept environment I would recommend the make your user cluster-admin in the whole cluster. This will give all the possible privileges to your user. Of course this in't recommended for every user in a 'real' environment.
First you need to authenticate with the 'default admin' which is created after the installation. This default admin-user isn't working with the normal user/password authentication. It's using a client certificate.
oc login -u system:admin --config=/etc/origin/master/admin.kubeconfig
Now you will see a list of the available projects (default, openshift management, etc). Now you're able to give cluster-roles to other users.
Make your user cluster-admin over the whole cluster
oadm policy add-cluster-role-to-user cluster-admin (youruser)
Now you have the cluster-admin privileges inside the whole cluster. You are also able to give privileges for some user in a specific project and not in the whole cluster. Than you have to use:
oadm policy add-role-to-user <role> <username> (in the current project)
This will give the role to a user, but only inside the project from where you've performed this command.
For more information about the avaiable cluster roles and policies I will point to the official documentation.
I raised a defect with Openshift Team as pointed out in the Support Link.
https://docs.openshift.com/online/getting_started/devpreview_faq.html#devpreview-faq-support
Here is the response i received from Support Team.
It seems that you have issued a bug and followed up for this already:
https://bugzilla.redhat.com/show_bug.cgi?id=1368862
After the cause is investigated, our operations team will sure clean up the project manually for you to allow you continue working with the developer preview
Latest update:
The project has now been cleaned up and you should be able to create a new project.
I am able to create Project in Openshift now.
I have a simple VB.net console application that displays the current user, waits for key input, and then exits. It uses the following call to display the information:
System.Security.Principal.WindowsIdentity.GetCurrent.Name.ToString()
If I create a remote app hosting this application, and create an azure user that has rights to run the remote app such as;
thisisa#test.onmicrosoft.com
When this user connects to the remote app the output of the line of code above would look something like;
YLSDAAYU0007\thisisa_000
Is there anyway of reading the user running the remoteapp at the time? in this case, I am looking to obtain thisisa#test.onmicrosoft.com ?
Catalin from the RemoteApp team here. You have stumbled across one of our implementation details here :)
Windows does not allow automatic login with Azure Active Directory (AAD) users: they only allow users that have Microsoft Accounts or domain accounts in case the collection is domain joined. We are working around this limitation by creating a local user on the VM and logging in with that user instead of the AAD user.
If you have any more questions about this, feel free to contact me: catalda ＠ microsoft com
I'm trying to configure LDAP authentication for teamcity but can't get it to work. I already configured some other services on this server to authenticate using LDAP and had no problems (so it's not fault of the DC).
Following describes my config file:
java.naming.provider.url=ldap://192.168.0.123:389/DC=server,DC=example,DC=com
java.naming.security.principal=ldap-user
java.naming.security.credentials=jE&4i.%$lpDr3#?
java.naming.security.authentication=simple
teamcity.users.login.filter=(&(sAMAccountName=$capturedLogin$)(memberOf=CN=Group1,CN=Users,DC=server,DC=example,DC=com))
teamcity.users.username=sAMAccountName
teamcity.auth.loginFilter=[^/\\\\#]+
teamcity.options.users.synchronize=false
teamcity.options.groups.synchronize=false
When I set authentication to 'none' it works (but I can't restrict access to a specific group). I also tried using the full user name (incl. domain; i.e. DOMAIN\ldap-user) and also tried to use full DN instead, but it didn't change anything.
In log i see that the ldap server returns error code 49, which means that the binding failed. Like mentioned before I already configured other services on this server to authenticate with the same ldap server and the same binding user and had no problems.
Does anybody know how to solve this issue?
Thanks in advance!
This is my configuration and It working fine. The synchronization is allowed so information like email and name there are no available but enable the login with NT Id and Credentials
java.naming.provider.url=ldap://amer.xxxx.com:389/DC=amer,DC=xxxx,DC=com
java.naming.security.principal=CN=SRVAMR-xxx,OU=CMAPPS,OU=Service,OU=Accounts,DC=amer,DC=xxxx,DC=com
java.naming.security.credentials=Pf867955
teamcity.users.login.filter=(&(sAMAccountName=$capturedLogin$)(memberOf=CN=AMR-GENOME-L,OU=GMA,OU=Security,OU=Groups,DC=amer,DC=xxxx,DC=com))teamcity.users.username=sAMAccountName
I Hope help you
I trying to connect to em console through wlst. But I could connect only to weblogic admin console. I need to change some of the mediator properties(soa-infra which is a web application) through em console. Can anyone please help me in connecting to emconsole and thereby changing the mediator properties.
For this I executed oracle_home/oracle_common/common/bin/wlst.sh
Everything goes through the admin console, since that controls the entire domain and deployments/applications. The following links all have examples on how to edit soa-infra properties:
http://rreddy.blogspot.com/2012/03/wlst-soa-mbeans-examples.html
http://bibeksoa.blogspot.com/2013/10/wlst-script-soa-process-deployment.html
http://www.qualogy.com/wlst-change-script-to-soa-common-bpel-an-bpmn-properties/
http://go2kavinkumar.wordpress.com/2011/08/28/using-wlst-to-manage-web-service-policies/
Specifically you want to grab the Application=soa-infra object to use it.
Make sure that you have the EM console installed. It may not me installed in your domain by default (unless you checked it when creating your domain).
You can add the EM console by running config.sh from your domain and selecting Enterprise Manager console from the list. Then you should be able to access it via
http://admin_server_url:port/em
We've been trying without much success to enable LDAP user authentication for the Worklight Application Center. We've carefully followed the instructions here:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
First, we created the LDAP repository in the WAS console and added it to the federated repositories config:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fappcenter%2Fc_ac_was8_ldap.html
Then we configured the LDAP authentication for users and groups following:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
Finally we enabled ACL management with LDAP as suggested by:
http://pic.dhe.ibm.com/infocenter/wrklight/v5r0m5/index.jsp?topic=%2Fcom.ibm.help.doc%2Fwl_home.html
After the server restart these are the results:
Worklight Console: Works OK.
Application Center: Shows a ?????? in the user space with the following error in every screen related to users: FWLAC0401W: No user appears to be logged, check the Application Center security configuration.
Worklight WAS Console: We are locked out. The LDAP users do not work, the initial worklight/worklight user does not work. The only way to get in is changing the security.xml for the instance to get back in and rollback the security changes.
What are we doing wrong?
Is there a more "tutorial like" documentation to accomplish these tasks, we might be making some mistakes following the infocenter.
About the application center effect: Technically, the message means that the Web Security Context does not contain a principal (i.e. a user name). In general, Application Center must be configured so that the login screen appears (is this the case for you?).
I know two possible reasons:
Application Security is disabled in WAS. Open the WAS console and select Security > Global Security. Ensure that "Enable Application Security" is checked. Ensure also that "Enable Administrative Security" is checked.
The appcenteradmin role is mapped to special subject "Everyone". Both the appcenteradmin role and the appcenteruser role cannot be mapped to this special subject, because it simply disables the authentication and hence the security context does not know anymore which user is logged in. Look in Applications > Application Types > WebSphere Enterprise Applications > AppCenter > Security Role to user/group mapping. Here you can see how the roles are mapped and you can change it.
Since you also have a problem with the Worklight WAS console, I would guess that your situation is 1., since 2. is local to the Application center and does not affect the WAS console.