I'm attempting to use the LDAPAuthenticator class found here to configure JupyterHub on EMR.
I'm querying ActiveDirectory through LDAP to get the authorized users, which are members of a specific AD group.
Problem I'm running into is that with this specific implementation, it expects the user objects to have a few specific user attributes that the objects don't have as of now and I'm not allowed to change them.
The ideal workflow would be, LDAPSEARCH queries ActiveDirectory for a specific AD group, and on return it creates users for the members of that AD group, it should create linux users and directories for the users.
I'd like to know if anyone else has run into this sort of issue and overcome, thanks!
If you get stuck in the same place, I ended up using this:
https://github.com/hansohn/jupyterhub-ldap-authenticator
and it work as expected.
Related
As from the title need to allow an external user to start/stop the instance he will work on and nothing else, it's a topic I found already answers, and did setup for the specific project the a custom role "StartStopCE" with these permissions:
compute.instances.get
compute.instances.list
compute.instances.osLogin
compute.instances.reset
compute.instances.resume
compute.instances.start
compute.instances.stop
compute.instances.suspend
serviceusage.services.list
Testing with one of my secondary Google accounts (not the one I'm Owner in GCP) all is working fine and I'm allowed only to list the VM Instances and start/stop/etc.
The external user was allowed to do so only the first time we was experiementing with the various persmissions, next when he tried to start the instance this disappeared after he started it, and after that he got only this page trying to access the VM Instances list
We have tried to delete and recreate his user, use a second Google user, logout/login, change browser, delete cache.
My test user has the very same assigned role and worked fine, I don't know what elese to check.
I a newbie to AWS. My requirement is to add field-level, document-level, and collection-level permissions for reads and writes for AWS DocumentDB. One collection should accessible only from one microservice and the document should be modified only by the owner of the document(i,e user document can be modified only by that user)
I have done enough research and found, adding a restriction for accessing a DB can be done using Role-Based-Access-Control if we want to allow only for one tenant, but didn't get a clear idea of my problem statement i.e managing collection-level, document-level, and field-level permissions
Is there any other way to achieve this..?
Any help will be appreciated
I created an instance with Debian 9 and was following the instructions on Google's site here. I have done this before successfully. All was going fine, but now when I do this part:
DISPLAY= /opt/google/chrome-remote-desktop/start-host \
--code="4/xxxxxxxxxxxxxxxxxxxxxxxx" \
--redirect-url="https://remotedesktop.google.com/_/oauthredirect" \
--name=
I get the error
Adding user newuser_gmail_com to group chrome-remote-desktop
ERROR:Failed to access chrome-remote-desktop group. Is the user a
member?
Can anyone help me out here? I notice that when I did this previously, the username create was not newuser_gmail_com, but rather simply newuser. Any suggestions you have would be much appreciated. Many thanks!
I found the answer, but this raises a possible bug for the Google Cloud team. The bug occurs if I add enable-oslogin = TRUE as a metadata. This causes the chrome-remote-desktop to fail.
When a user is added to a group (chrome-remote-desktop in this case), the change is not reflected in existing sessions until the user logs out and back in. To work around this limitation, Chrome Remote Desktop attempts to use sg to access the new group from the existing session. It looks like this isn't working for some reason on this system (apparently OS Login related?), so starting the host fails.
It should be sufficient to log out and back in. Once logged back in, very that the output of groups contains chrome-remote-desktop, then try running the headless setup flow again. (Make sure you generate a new command, as the --code argument is one-time-use only.)
I tried to create new AWS key pairs and the option to create disappeared
Does anyone know why?
It would be worth checking the IAM permissions associated with the User who is trying to create the key pair. Contact the Administrator (presumably you?) and investigate. I would suggest creating a Group with Permissions and adding them to that.
I performed an experiment and added aDeny policy to my IAM User that prevented me from being able to create a keypair.
I then tried to launch an instance and the option to create a keypair (in the dialog box you show above) was still available. So, the display does not vary according to permissions.
Therefore, something else is causing your situation. I would recommend trying it in a different browser. Also, check the underlying HTML to see whether the option is coded on the web page. Something is causing it to disappear.
I am adding users to my ca-server's config file. I want to know what are the differences between roles, affiliations and attributes?
In tutorials I can see that roles is assigned to one of these: "client,user,peer,validator,auditor,ca". I want to know can be use some other role? If a user is assigned "client" role then can he have a validating role running with that identity. What's the difference between "client" and "user"? What's the difference between "peer" and "validator"? And also what is auditor specifically.
I think affiliations are used to categorize identities. Is that right?
Identity type can be any arbitrary string as far as Fabric CA is concerned.
I think of affiliations as hierarchical tags. Each identity can be tagged (affiliated) to (with) one affiliation in the hierarchy. When an identity is associated with an affiliation, it is affiliated with that and all the child affiliations.
1) Affiliations are currently used during registration and revocation. You can read more about registration/revocation at https://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html
Attributes are key-value pairs that can be associated with an identity. hf.Registrar.Roles, hf.Registrar.DelegateRoles, hf.Revoker, and hf.IntermediateCA are currently in use with in Fabric CA server. These are used to make access control decisions. Currently attributes are not used in any other Fabric components, afaik.
For example, if an identity with “hf.Registrar.Roles” attribute set to “peer,app,user” and affiliated to org1.dept1, can register identities of type peer, app, and user, (but not orderer) that are affiliated with org1.dept1 (but not identities affiliated with org1 or org1.dept2)
I hope this is helps