I setup a little server and have it authenticating with ldap.. is there a way to restrict which ldap user can login via ssh without adding an account to the opensuse box?
1 - Create a group on LDAP using YaST's User and Group Management, for instance "serveradmins".
This will create a entry on your LDAP server under the group OU.
2 - Add the allowed users to this group, also using YaST
3 - On the servers you want to restrict the access, edit the /etc/ldap.conf, making sure the following instructions are present (uncommented), mind changing the DC= parts to your configuration:
pam_groupdn cn=serveradmins,ou=group,dc=example,dc=com
pam_member_attribute member
Let me know if this worked well for you. I have this working on OpenSUSE and Ubuntu machines.
Related
I am using sonarqube 8.9.7 version.
I am trying to do authentication using LDAP. we have 2 groups in LDAP one group is admin and another one is normal user.
sonar.security.realm = LDAP
sonar.authenticator.downcase=true
ldap.url=ldap://<IP address>
ldap.bindDn=CN=BInd username ,CN=Users,DC=company name,DC=in
ldap.bindPassword = BindPassword
ldap.authentication=simple
above one is for bind this is working fine.
ldap.user.baseDn=cn=Users,dc=CompanyName,dc=in
ldap.user.request=(&(objectClass=user)(sAMAccountName={login})(|(memberOf=cn=Sonarusers,cn=Users,dc=companyName,dc=in)(memberOf=cn=SonarAdmin,cn=Users,dc=companyName,dc=in)))
ldap.user.realNameAttribute=cn
ldap.user.emailAttribute=mail
User access is also working fine giving access only to those groups.
ldap.group.baseDn=CN=Users,DC=companyName,DC=in
ldap.group.request=(&(objectClass=posixGroup)(member={uid}))
ldap.group.idAttribute=sAMAccountName
This is group access
for this I am not able to configure things.
I have 2 groups in LDAP sonarUsers and sonarAdmin and created same group in Sonarqube and give
permission for sonarAdmin.
please help me to sync the groups.
Thanks in Advance
I found the solution.
the mistake was from filter i was using wrong object class
SonarQube v5.2
I am trying to create a technical user (one that is authenticated locally and not against our LDAP). I have added a user name to the conf/sonar.properties file and restarted SonarQube. But, when I log in (as an administrator), the new user doesn't show up in the Administration | Security | Users list. We have two previously defined technical users (including admin) which do show up.
The admin guide doesn't say much http://docs.sonarqube.org/display/SONARQUBE52/Authentication.
Is there another step needed to create a technical user?
You need to manually create the user in SonarQube, it won't be automatically at startup.
Note that the SonarQube version you're using is no more supported, you should migrate to the latest LTS version 5.6.X => local users (previously known as technical users) are better managed :
- No more need to update sonar.properties
- You just have to create a user from the web server, this user will automatically be considered as a local user.
I've updated http://docs.sonarqube.org/display/SONAR/Authentication in order to remove the "Technical" word.
Am trying to configure Single sign-on using FreeRadius.
Scenario:
I have a fully configured LDAP (389 DS) Version-2.1 with few users and groups (in CentOS6).
I have installed FreeRadius (latest stable version) (in CentOS 6).
Configured FreeRadius to listen the above LDAP server.
I have made a client system (CentOS6) as radius client using pam_radius module. Now, am able to login to NAS with the LDAP credentials and getting logs correctly in FreeRadius.
Now, I want to implement single sign-on in this setup since I want to added some other devices like Firewall(Sonicwall) to authenticate.
I couldn't find any good docs to configure this.
Can someone please suggest me how to configure Single sign-on in the above setup?
For firewalls most people just use the accounting data to start and stop sessions as appropriate. This is usually triggering a script from within the accounting {} section of the freeradius server, creating the session on Acct-Status-Type == Start and destroying it on Acct-Status-Type == Stop.
If the PAM module sends Interim-Updates, you can record those in a database, and also set a 'lastupdated' timestamp. You then have a cronjob to check for rows where NOW() - lastupdated > (interim-interval * 2), and for those rows, delete the session on the firewall and close out the session in the database.
There is no proper SSO mechanism I know of which runs purely over RADIUS, the Project Moonshot guys were trying to get something working with SAML and a special EAP method, but it's probably too complex for what you want here, and not supported by PAM anyway.
The problem is as follows:
- I've got users defined on server A (domain controller),
- I've got SharePoint Farm installation on server B (fresh install)
After installation i have started the Profile Synchronization process, so i've got all the required users in sync. After i created a site i've assigned USER1 as its administrator / owner.
As i understand the USER1 user should have access to:
- site settings / permissions
- site content
Unfortunately i stuck with the situation where user can login on his my-domain\USER1 account, and he can access MOST of the pages. The rest:
example.net/ (http://example.net/default.aspx IS accessible)
example.net/test/ (http://example.net/test/SitePages/Home.aspx IS accessible)
example.net/test/SitePages/
causes re-authentication.
It is really easy to solve by adding users / group defined in PDC to local WSS_WPG group, but i don;t think this is the solution.
I will really appreciate your help !
The problem was in AD configuration.
Domain Users must have Bypass Traverse Checking enabled to avoid that issue.
For more information you can check following links:
http://technet.microsoft.com/en-us/library/cc787794%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/cc739389%28v=ws.10%29.aspx
www.windowsitpro.com/article/performance/how-to-use-the-bypass-traverse-checking-user-right
I am trying to figure out what is going on. Here is our setup:
We have four SQL servers that are in replication with each other.
We add a new user to Windows Active Directory and add them to a group that is in SQL Server that we have been using for ages.
The new user, when trying to authenticate using Windows authenication returns that error in the subject line. But, any users that were previously in Active directory work fine.
At one point I had gotten SQL Server "caught up" becauuse we had a group of users that could not log in because of this error. I did some changes to the SPNs and ended up making it so no one could log in. Then I realized how the SPNs were supposed to look and fixed it. Then I guess some magic happened and those users were able to authenticate. I thought it was fixed, but it is obviously not as we had to add one new user and they cannot authenticate.
What is interesting is that the user can authenticate with three out of the four SQL Servers. It is only this one server that is working incorrectly. I set up two SPNs for the SQl Service on this sql server.
They look like -
MSSQLSvc/[servername].[domain].local:1433
MSSQLSvc/[servername]:1433
These are actually registered to the Service account that we use for the SQL Servers. What is interesting is that I can't find the SPNs for the servers that are working anywhere.
Any help would be appreciated!
Edit: Also, another point to note is that if I try to add the user directly as a login into SQL server. I right click Logins and click Add Login then click search. I then type in [Domain]\[Username] and click check names. It validates the name as being correct. Then I click OK. And then OK again, and it gives the Error Windows NT user or group '[Domain]\[Username]' not found. Check the name Again.
I thought it was fixed, but it is obviously not as we had to add one
new user and they cannot authenticate.
The user has to relogin in order to pick up the new group. Otherwise, it's kerberos ticket is still using the old group membership information in its PAC
These are actually registered to the Service account that we use for
the SQL Servers. What is interesting is that I can't find the SPNs for
the servers that are working anywhere.
I think what happen is that you have one SQL Server with SPN setup properly while the other three SQL Servers with no SPN setup at all. So, you are going to use Kerberos on this particular server while NTLM on the other three.
As mentioned before, when you are using Kerberos, you have to either purge the ticket using some tools or you have to relogin in order to pick up the new group membership. You can also try to lock the screen and then unlock it. If I remember correctly, this should also refresh the ticket.
Unlike Kerberos, NTLM doesn't carry the group memberhsip data. After SQL Server authenticated the user using NTLM, it will find the authenticated user's group membership, including the new group you just added.