We are running GitLab EE Version 8.17.0-ee. To manage the amount of Users, we want to add and administrate them via ldap groups. We know that there are some ldap settings in the gitlab.rb file. We can definde a user base and also a admin group at
gitlab_rails['ldap_servers'] = ...
[...]
# ## EE only
# group_base: ''
# admin_group: ''
# sync_ssh_keys: false
#
But we miss the option to define user groups which we can use to automatically give permissions after those users are assignet to specific groups/projects.
Seen in this video there was a feature called Linked LDAP Groups. But in the newest version I cant find it. Is there any other way to configure GitLab to perform this?
I think I found an possible answer to my question. We forgot to set the group_base in the gitlab.yml file. link
Related
We are going to change cassandra setting from authenticator: AllowAllAuthentication to authenticator: PasswordAuthenticator
to enable role-based authentication. There will be two roles:
admin which is a superuser
read-only which is only allowed to read.
I would like to provide backward compatibility for users of the cassandra cluster. More specifically,
many users use
shell script that uses cqlsh
python cassandra package
php cassandra package
to only read data from cassandra. Currently they don't specify any username or password. Therefore
I would like to make read-only role some sort of a "default" role, i.e. if no username and password provided,
then the role is automatically set to read-only so the users can read data and thus clients don't need to change their code.
Is there a way to do this? I'm currently having trouble in the following two parts:
the default user is cassandra if there is no role / user specified in cqlsh. I did not find a way to set default user / role.
and for the default user cassandra, I still have to set a password for it.
Any suggestions would be appreciated! Thanks in advance.
I come from an oracle background, were I've done "sqlplus "/as sysdba"" for years. I like it because the O/S authenticates me. Now, there is something similar in Cassandra, but it isn't secure. Basically in your home directory there is a subdirectory called ".cassandra" (hidden). In that directory there is a file (if there isn't, create one) called "cqlshrc" (so ~/.cassandra/cqlshrc). That file you can add authentication information that will allow someone to log in by simply typing "cqlsh" without anything else (unless you're doing remote where you need "host" and "port"). The cqlshrc file has, among other things an authentication section that looks like this:
[authentication]
username = <your_user_name>
password = <your_password>
So you could simply put your desired username and password in that file and you're essentially able to connect without supplying your username and password (You could also run "cqlsh -u your_user_name" and it will find your password in your cqlshrc file as well).
You can see a few obvious issues here:
1) The password is in clear text
2) If you change the password you need to change the password in the cqlshrc file
I do not recommend you use the "cassandra" user for ANYTHING. In fact, I'd drop it. The reason is because the cassandra user does everything with CL=quorum. We found this out when investigating huge I/O requests coming from OpsCenter and our backup tool (as you can see, we use DSE). They were all using cassandra and pounding on the node(s) that had the cassandra authentication information. It's baked into the code apparently to have CL=quorum - kinda dumb. Anyway, the above is one way to have users log in with a specific user and not provide credentials making it pretty easy to switch.
Hope that helps
-Jim
I'm using ApacheDS as directory server which is used in applications like Gogs (Git server like GitLab). My idea is to create groups like gogs-users and restrict the login to those group, so that only users who are member of that group are able to login. I have created a groupOfNames for this and a testuser, which is added to the gogs group.
The type of gogs-users is groupOfNames and it has an attribute member which contains the DN of my user (uid=testuser,ou=Users,DC=example,DC=com). So I'm able to see, who is a member of this group.
But I would like to see all groups where a user is a member of. When I open the testuser, I see no attribute that could tell me, that he's a member of gogs-users. I remember that the proprietary Active Directory had an attribute called memberOf whch was queryable in a filter like (&(objectClass=inetOrgPerson)(memberOf=CN=gogs-user,DC=example,DC=com)). That would be exactly what I need.
How can I get this in a free LDAP implementation? I see no way except defining a custom attribute - Which I had to maintenant per hand. That's not good, I would like to have an automated solution, that keep care of those attribute.
Things I already tried
https://stackoverflow.com/a/34502363/3276634 No changes
https://morenews.blogspot.de/2010/12/adding-active-directory-properties-to.html No changes, too
Note: I did a complete reset after each scheme import, to make sure, that my tests are not influenced by previous changes.
Here are Queries that will go either way but ONLY work for Microsoft Active Directory:
Resolves all members (including nested) Security Groups (requires at least Windows 2003 SP2):
(memberOf:1.2.840.113556.1.4.1941:=CN=gogs-user,DC=example,DC=com)
And
All Groups a User is a member of including Nested Groups
(member:1.2.840.113556.1.4.1941:=CN=UserName,CN=Users,DC=YOURDOMAIN,DC=NET))
We plan to implement a company-internal portal with Liferay 6.2. Since many of the team members are not within the company's network, the access has to be allowed from the internet.
Now I see a big problem with the Guest role, since it 1) can access Guest-viewable content without login and 2) this is the default selection when for example uploading a document.
What I really need, is that only the login page is generally viewable, but all other sites and content is only visible to logged-in users, without the need to explicitely assign the permissions for each item correctly.
So the question is, can I prevent the guest role to access anything beyond the login page, so to say eliminate it from everything within the portal?
Update:
It was proposed to use only private pages. While this might work, it implies as far as I know, that each user has to be member of the site. But then it's no longer possible to have a site structure with different users participating in different sites and still be able to view public infomation (meaning public for all logged-in users) - or am I wrong?
Update 2:
I agree to a solution where one has to prevent the assignments to the guest role programmatically, via hook or via deeper changes in liferay. Yet, I like to double-check that administrative and think of a periodic database job or program using the API which check for relations to the guest role which came in around the hook or by wrong permission settings of a user and delete them again. How could that be done?
When a document is uploaded through a private page, the permissions actually default to be not accessible to "Guest". This is guaranteed easiest if you don't have any public pages.
Also, you can access the API and change the default permissions once a document gets uploaded (no need to override core Liferay functionality like defaults): Just write a service hook that overrides the upload of a document with a version that sets the permissions you want right after a document has been uploaded. This will catch all other upload attempts, e.g. through services, Webdav etc.
Edit (after your comment): Added the link to Dev Guide. The actual use of the API is a bit too much to update this answer with on the fly. You might want to look at old examples like sevencogs (part 2) to get used to the actual API, but DevGuide will describe how to write the plugin in the first place.
You could still use the public pages etc. and disable the guest's VIEW permission on every element but the login page and it's resources.
Now, as you have already noticed, the fact that, by default, whenever creating any content the Guest gets the VIEW permission is a substantial problem.
I'd suggest to simply override the <guest-defaults> values in Liferay's core portlets' resource permission files (the ones in ROOT/WEB-INF/classes/resource-actions/) to remove these default values. If it's not clear to you on how to do it, see, e.g., this forum topic: https://www.liferay.com/community/forums/-/message_boards/message/486154 .
All you need to do is delete all public pages. Every page that you create should be private. Don't worry about login page, reset password and self-registration (if allowed), by default they are public.
Hope this helps.
Is it possible to set the Perforce server to by default don't let the users check out a directory, instead of letting everybody update their view-spec to exclude that directory?
Eg: if you would like to check out //code/heavy/stuff you must explicitly add that directory to your view-spec instead of adding a -//code/heavy/stuff yo your spec.
You can install a trigger on the server that generates the default clientspec for a user. With this flexible tool, you can achieve a number of designs. The idea is that when a user creates a new clientspec, the server would fill it in with something other than the default //depot/... mapping for each depot.
One simple idea would be to define the default clientspec to include -//code/heavy/stuff mapping automatically.
Another more advanced idea would be to check to see what groups the user is a member of, and then auto-generate a clientspec appropriate for that user based on his group membership.
If you just want to block people from getting it, then it might be possible with permission mapping.
But then they would never by able to access it, even if they change their client spec.
Maybe you need to (re-)structure your repository so that the heavy part isn't in most users' client specs.
I wanna know, how I can set user name and password for each user in TortoiseSVN and I already did these steps to made repository:
- Created a file then created repository in this file.
- Changed " svnserve.conf " in conf file.
- Then set all user and them passwd in conf file.
- I changed authz to access my repository also including in conf file.
I try and try to Authentication many of users for each project but as file not Http.
I hope to someone help me in this issue.
I'm having trouble understanding your question, but it sounds to me like you ought to move to integrating Apache with SVN. That will give you the ability to give users different levels of access on a per-directory basis.
Refer to the sectino Per-Directory Access Control in the svn book:
It's possible to set up finer-grained
permissions using a second Apache
httpd module, mod_authz_svn. This
module grabs the various opaque URLs
passing from client to server, asks
mod_dav_svn to decode them, and then
possibly vetoes requests based on
access policies defined in a
configuration file.