I configured Openldap2.4 on RHEL6.5.
i applied default password policy on my ldap tree.
But, Account lock has been effectively applying only when i do su - username with wrong password .
But when i tried to check with login with putty session or direct ssh it is not applying.
Can any one please help me on the above issue ?.
when i tried using sudo su - testuser2.4
pwdFailureTime: 20150427095439Z
pwdFailureTime: 20150427095445Z
pwdFailureTime: 20150427095451Z
pwdAccountLockedTime: 20150427095451Z
But when i tried direct ssh or putty session with 3 failures still the
policy not applied.
You have to avoid using the managerDN user. That's for use by OpenLDAP itself, and it bypasses all overlays, specifically this one. The overlay will work if you're logging in as a user within the DIT.
Related
Im trying to conect gitlab with ldap to centralize my authentication.
Im having a problem when i try to log in because gitlab blocks the users.
The base_dn where the users are is ou=People,dc=dominio,dc=com
When i try to log in all works fine until Gitlab make a sync and block the user because on the gitlab database the base_dn is saved in lowcase.
LDAP account "uid=user1,ou=people,dc=dominio,dc=com" does not exist anymore, blocking GitLab user "Usuario" (user1#dominio.com)
Gitlab is able to read all the info from the user in theLDAP and also create the user on the gitlab system(full name, email, etc).
User "Usuario" (user1#dominio.com) was created
But later block the user and im not able to log in, every time i unblock manually, the gitlab block again.
Here all the process:
User "Usuario" (user1#dominio.com) was created
(LDAP) saving user user1#dominio.com from login with admin => false, extern_uid => uid=user1,ou=people,dc=dominio,dc=com
LDAP account "uid=user1,ou=people,dc=dominio,dc=com" does not exist anymore, blocking GitLab user "Usuario" (user1#dominio.com)
When i check in the user profile they show this info:
LDAP uid: uid=user1,ou=people,dc=dominio,dc=com
In the LDAP the real path is:
uid=user1,ou=People,dc=dominio,dc=com
Some idea how i said to gitlab rescpect the upercase or not be case sensitive?
LDAP itself is case-insensitive, so in queries against LDAP it doesn't matter. GitLab tries to normalize all DNs to lowercase before comparing values on its side since GitLab itself is case-sensitive.
With that in mind, I'm not clear where you're running into problems. It sounds like it's probably a bug if it really is related to the case. It's also possible there's another issue causing the user sync to block your user(s).
If you have clear reproduction steps the best bet is probably to create an issue at https://gitlab.com/gitlab-org/gitlab-ce/issues. Tag the issue with ~ldap and ping me (#dblessing). Happy to try to reproduce.
Finally i found the solution.
the user_filter: i used have some issue, dont support omniauth-ldap's custom filter syntax.
I was using
user_filter: '(&(objectclass=*)(memberof=cn=gitlab,ou=Groups,dc=dominio,dc=com)(uid=%{username}))'
But i change for somnething simple as:
user_filter: '(memberof=cn=infra_gitlab,ou=Groups,dc=dominio,dc=com)'
And start to works...
I created an application on existent OpenShift project by pulling a docker image from remote repo.
The pod is created but fails with STATUS "Crash Loop Back-off".
Invesitgating the reason using
oc log <pod id> -p
it appears a list of unsuccessfull "chown: changing ownership of '...': Operation not permitted
I found this is due to non predictable user id running the container.
According to
https://docs.openshift.com/container-platform/3.6/admin_guide/manage_scc.html and various post here and there,
it seems the solution is to relax security policy:
oc login -u system:admin https://<remote openshift endpoint>
oadm policy add-scc-to-group anyuid system:authenticated
If this is the solution, I don't know, because I cannot get out of 1st problem:
oc login -u system:admin
asks for login/pwd and after print an error
error: username system:admin is invalid for basic auth
I guess there is the need of a certificate, a token, something secure, but I cannot understand how to generate it from Openshift, or
if there was a key pair to generate locally (of which kind) and how to bind the key to the user. Furthermore, checking in the web console
I cannot see that kind of user (system:admin).
Am I missing something?
Thanks a lot,
Lorenzo
Due to some requirements, a set of machines I use needs to have 2 KDCs defined in /etc/krb5.conf. On top of that, the realm that doesn't contain user principles (just host and service principals) must be specified as the default realm under libdefaults.
The user principals are stored in the other realm and ssh is supposed to work through that realm. The sshd config also uses PAM. In PAM, I've overriden the default realm with realm=MY_SECOND_REALM for the account interface and my ssh logins now work.
The only problem is that my logins now require a password -- each time despite my valid tickets for the MY_SECOND_REALM.
I'm also using sssd. Quite a setup!
Did I miss something simple?
After a few hours of playing with my pam auth modules, I figured out a way to circumvent the problem by using the realm=MY_SECOND_REALM as an argument to the pam_krb line in the account section.
From the pam_krb5 man page:
realm=realm
overrides the default realm set in /etc/krb5.conf,
which > pam_krb5.so will attempt to authenticate users to.
I am having trouble working through the Compute Engine Quickstart: Build a to-do app with a MongoDB tutorial. (edit: I am running the tutorial from within the compute engine console; i.e. https://console.cloud.google.com/compute/instances?project=&tutorial=compute_quickstart)
I SSH into the backend instance. I enter the "gcloud compute" command as copied from the tutorial. I am prompted to enter a passphrase. The following is returned:
WARNING: The public SSH key file for gcloud does not exist.
WARNING: The private SSH key file for gcloud does not exist.
WARNING: You do not have an SSH key for gcloud.
WARNING: SSH keygen will be executed to generate a key.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
...
<< Identifying detail ommitted >>
...
**ERROR: (gcloud.compute.ssh) Could not fetch resource:
- Insufficient Permission**
I had run through this stage of the tutorial on a previous occasion with no problems.
I am working from a Windows 10 PC with the google-cloud-sdk installed. I am using google chrome. I have tried in both regular and incognito modes.
Any help or advice greatfully received!
DaveDub
It looks like the attempt to SSH is recognising the instance in your project, but the user doesn't have the required permissions to access the machine.
Have you tried running:
gcloud auth login
and completing the web-based authorization to ensure you are attempting to access the machine as the correct (authenticated) user? This process ensures the Cloud SDK you are running inherits the permissions of the user specified in the web-based authorisation. See here for more information on this.
It's also worth adding the link to the tutorial you are following to your question.
Besides the accepted answer, be sure you are in the correct gcloud project
gcloud projects list
Then
gcloud config set project <your-project>
I just ran into this for yet another reason. Google has always had poor handling of multi-user auth conflicts with their business products. Whatever you sign into a clean chrome session with 'first' gets a 'special', invisible role. I've noticed with gsuite that I get 'forced' into that first user when I try to access the admin panel, and the only way to escape is to make sure that whatever google user I use for the gsuite admin is 'first', or open an incognito window. I've seen this bug for years, can't believe it still exists.
Anyways, I ran into a similar issue. Somehow I was the wrong google user, so the link I got when copy/pasting out of 'connect with gcloud command' was implying wrong google user. Only noticed later when I just gave up and used the terminal that I was not my normal user... So, might look into that.
We updated our Couchbase from 4.6 Community edition to 5.0.0-2873 Enterprise Edition for testing purposes and our software using the java-client started throwing InvalidPasswordException when trying to open a bucket.
As I've found, every newly created bucket has authType='sasl' and a randomly generated saslPassword.
I've tried creating a bucket using the CLI instead of the GUI:
couchbase-cli bucket-create -c localhost:8091 -u Administrator -p password --bucket=general --bucket-ramsize=1300 --bucket-type=couchbase --bucket-password=
I got the following error:
ERROR: unrecognized arguments: --bucket-password=password
I also tried the bucket-edit function with the same result.
According to the documentation the argument should be valid.
I also tried using the REST API to change bucket authentication (and similarly password), but even though this didn't throw any erros, the authType and the password remained the same.
curl -X POST -u Administrator:password -d 'authType=none' http://<host>:8091/pools/default/buckets/general
Again, according to the documentation this should work.
If I query the bucket information for the sasl password and provide that for the openBucket function then the connection works, however we really don't want to use this feature in our system.
So, any other ideas how it would be possible to remove the bucket authentication in our 5.0EE Couchbase setup?
In Couchbase 5.0 we no longer support bucket passwords and have moved to using role based access control when connecting to buckets. This means that in 5.0 the standard (pre-production) way to connect to a bucket is by using the Administrator user and password that you created when setting up the cluster. In case you're unsure what the Administrator user is, it is the user you create when you first go through the Couchbase setup wizard or the it is the username and password you specify on the command line when running the couchbase-cli cluster-init command.
One thing to note is that using the Administrator user/password is the standard pre-production workflow. I would recommend that when you go into production you create separate users for your application which only have access to cluster resources they need to access in the cluster. You can do this by going to the Users tab in the Administration Console and creating a new user and giving them the Full Bucket Access role which is the standard role that applications should have.
You might now be saying to yourself that this all sounds great, but when I use the Administrator user/password I still am having issues. If this is the case the reason is because you have Couchbase 5.0, but your SDK is not new enough to handle the new RBAC authentication mechanism in 5.0. The workaround for this is to create a user in the Users tab with the same name as the bucket and give that user the Full Bucket Access role. You can then use this user to authenticate.
One last thing to mention is that during an upgrade from a pre-5.0 cluster to a 5.0 cluster Couchbase will automatically create a user for each bucket. The each user will have the same name as one of the buckets and the password for that user will correspond to the bucket password. This is done mainly to ensure that there is no application downtime during an upgrade. After upgrading the cluster the next step should ideally be to upgrade the Couchbase client library to have it start using RBAC authentication.
If you need to stay with old approach and no password you can use cochbase-cli with --rbac-username and --rbac-password "", but you need to specify password as "", e.g.
./couchbase-cli user-manage -c localhost:8091 -u Admin -p password --set --rbac-username <UserForBucket> --roles bucket_full_access[<BucketName>] --rbac-password "" --auth-domain local