Hello or Good evening,
I actually work as a trainee for a small society and one of the improvement that they want, is to have a central authentication server. After some research, we chose to use UCS (Univention Corporate Server) which handle a lot of tools that they want to use in the future. And my problem begin here ...
I want to do a authentication at computer startup and only authentication, by my UCS (no roaming profile or else). I just need to get a ticket to allow the user to have a single sign on, on the intranet (to access NAS or cluster for example). I know that an LDAP server run on my UCS because when I use univention-ldapsearch, I can see a big file with a lot of information ... However, I don't know which LDAP server it is. I have kerberos v5, slapd, pam (maybe), so everything for an SSO and authenticate a user.
What they want to have is this :
--> When a user start a computer, they can connect with their login/password from everywhere.
--> The home directory have to stay ONLY on the main user computer. (so the fact that they can connect from everywhere is more for accessing to data in the intranet)
--> They can access, with SSO to all device (allowed for the user) in the intranet.
Now :
I know :
how to add a user / group. UCS is very user friendly for that,
that an LDAP server is running on UCS.
that I have samba but i'm pretty sure I can do it without using it.
I don't know :
how to set up the authentication at startup (nsss doesn't want to install on UCS and the documentation from UCS using PAM don't take missing files inside UCS -_- ...),
Which LDAP server is running (not an openldap (no directory from them.))
If it's possible to create (ONLY) if it's not the main user computer, an empty home directory and how.
I don't know if someone is familiar with this tech, I hope so because it's more like : "I need a tutorial" than "RTFD" where, a lot of point are missing.
I prefer to specify that we don't have an heterogeneous network, all computer are linux based.
If someone can help me,
Please,
I spent the day trying to do one startup connection and nothing ...
(I can connect from a browser but it's just to change password. And we really need a central authentication).
Thank's in advance,
Regards.
Hello Black Butterfly,
I am working at Univention and know that UCS is quite versatile, so you can connect pretty much any box to it.
UCS comes with OpenLDAP and Kerberos which are closely connected (and even the PAM-Stack uses Kerberos in the end). The important part to know is, that OpenLDAP is running on ports 7389 (LDAP with StartTLS) and 7636 (LDAPS).
Samba/AD is optional and "only" needed if you have Windows(-like) clients. But since you said that you only have Linux boxes, you don't need Samba/AD.
Now, if you want to connect Linux/Unix-like clients to UCS, you will have to ...
1. create a computer object for the client in the UCS LDAP/management system. There's a webmodule for that: http://docs.software-univention.de/manual-4.1.html#computers::hostaccounts
2. configure the client:
- use UCS as nameserver
- use UCS as timeserver
- configure the LDAP-client to use UCS as LDAP-Directory server
- configure the Kerberos-client to use UCS as KDC/Kerberos-Realm
- use some kind of identity/group caching and bridging software like NSS and/or SSSD
Unfortunately every Linux distro behaves differently regarding the nitty-gritty details.
There is a straight forward tutorial on how to do this with Ubuntu - it's mostly copy&paste:
http://docs.software-univention.de/domain-4.1.html#ext-dom-ubuntu
What Linux distro(s) are you using at your organisation for the Linux clients? Maybe I can give you better advice if I know.
Regarding home directories: Do I understand correctly, that you don't want "Roaming Profiles" or shared home directories? That would be the default.
For further advice, you can also always refer to the Univention forum.
Related
I've just installed Chef (12), on a public facing server, along with the Chef Manage interface.
The user pivotal is created by default, but I can't find any obvious information about the security considerations, which are crucial for public web services.
As far as I see, it's not possible to login to the web interface.
Is there anything that needs to be performed on such user, after installation (eg. change password, rename it, disable permissions, etc.)?
That user is magic and internal to Chef Server. You will never touch it directly or be able to see it unless you do something very wrong like copying superuser authentication keys manually to a workstation.
Is ngrok a safe tool to use? I was reading a tutorial which recommended to use ngrok test API responses that I make to outside services that need to connect to my endpoints also.
There is no source code available for Version 2.0, considering it started as an open source project in 2014. I am suspect of any code that opens a tunnel to my localhost from the cloud. Pretty scary stuff especially without source code!
It opens up a tunnel to your dev machine, which is partially secured by obscurity (a hard to guess subdomain), and can be further secured by requiring a password. But you're still opening yourself up to ngrok itself, and the company is completely opaque (no address, no employees, no business name, no LinkedIn presence; all I can find is that it has 1-10 employees and is private; not even sure what country its based in). On top of that the code is not open-sourced. No reason to think they're not legit, but not a lot of information available to build trust.
You may be able to use ngrok and other local tunnel services with more security by encrypting the traffic. See https://security.stackexchange.com/questions/177280/end-to-end-encryption-for-localtunnel-ngrok-setup/177357#177357 for more information.
I found good rating, but vacuous information here:
http://www.scamadviser.com/is-ngrok.com-a-fake-site.html
The kicker for me is
https://developer.atlassian.com/blog/2015/05/secure-localhost-tunnels-with-ngrok/
where the Atlassian folks recommend it highly.
I think I am going to use it.
If anyone is concerning compromising their development environment, you can use Docker. There are many ngrok/docker projects but here is the one I chose: https://github.com/gtriggiano/ngrok-tunnel
for macOS, use "TARGET_HOST=docker.for.mac.localhost"
They now offer a service where you locally run only ssh, no need to run any of their code on your machine.
You run something like ssh -R 80:localhost:8501 tunnel.us.ngrok.com http. This connects to one of their hosts and forwards connections they receive back to your machine and the service you run on localhost:8501.
This seems secure to me, the only thing is that you don't know what information they collect and who is connecting to your exposed service. They print all connections, but it's their binary that does this and someone might well listen in without you noticing. You can check connections on your end, but you cannot be sure who it is that connects.
Ngrok is a convenient and highly secure utility for creating tunnels to locally hosted applications via a reverse proxy. This is a utility for publishing locally hosted applications on the web. style="letter-spacing: 0px;">Simply put, any locally hosted application provides a publicly accessible web URL to the . H. Either a Spring Boot or Nodejs based web application, or a webhook for a chat application, etc.
I have a special user, called udpate, whose shell is a special command that fetches any pending updates to our system.
I'd like to be able to open an ssh session with this user without any kind of authentication (password or ppk, or anything), so if anyone wants to update a system, they could do "ssh update#<>", without having to know a password, or have a pre-shared public key on the box.
Insecure, I know, but this is over a VPN, so it should not be a problem, and they will only run the update, and then be thrown out.
Can this be done?
VPN is not a good reason to avoid authentification when using ssh. Even if there is a way to do this, you shouldn't use it. Use a ssh-key is the best way to do it. If you really want to do thing like this, use the same key and distribute it on each box.
What did you do if the local network of your box is compromised ? You just have a security hole.
as this rfc points out, there is support for host based authentication https://www.ietf.org/rfc/rfc4252.txt
So using it carefully should be possible by following this tutorial https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Host-based_Authentication#Server_Configuration_for_host-based_authentication.
That may not be a final solution, but helping finding one.
But really, you should not do it for this usecase... Just offer a basic web endpoint which does only start the update process on the next cron run. I know, its not so "simple" but its a lot more secure.
Or if they have access to this server anyway, add a script with super user bit set which triggers the update.
Also, if you have a central server in your company, where everyone has access too, you can use this as step in between to host the key pair, so you dont need to manage X keys for everyone.
Or you use a more modern setup with puppet or anything, or you just configure the server to always update without user interaction needed....
what are the absolute security guidelines for a server with LAMP stack?
Also, you must make sure that you have changed Apache's administrative interface default password. It's the easiest way to hack a LAMP server.
I recommend you try denyhosts if you are using ssh to auto-ban IPs that try to hack your server using basic scripting techniques.
Also be sure your site folders (i.e. /var/www/) are owned by the server "user" this is somtimes "www-data" or "nobody" and I think even occasionally "apache", depending on your distro etc. From then on, be careful about the permissions, I'm sure you can google for permissions for web folders.
Update early and often (make backups before you do).
Subversion has multiple server types:
svnserve daemon
svnserve via xinetd
svn over ssh
http-based server
direct access via file:/// URLs
Which one of these is best for a small Linux system (one to two users)?
http:
very flexible and easy for administration
no network problems (Port 80)
3rd party authentication (eg. LDAP, Active Directory)
Unix + Win native support
webdav support for editing without svn client
slow, as each action triggers a new http-action approx. 5-8 times slower than svn://
especially slow on history
no encryption of transferred data
https:
same as http
encryption of transferred data
svn:
fastest transfer
no password encryption in std. setup: pw are readable by admin
firewall problems as no std.port is used
daemon service has to be started
no encryption of transferred data
svn+ssh
nearly as fast as svn://
no windows OS comes with build in ssh components, so 3rd party tools are essentiell
no daemon service needed
encryption of passwords
encryption of transfer
1 of those options is definitely a 'worst' one: file access. Don't use it, use one of the server-based methods instead.
However, whether to use HTTP or Svnserve is entirely a matter of preference. In fact, you can use both simultaneously, the write-lock on the repo ensures that you won't corrupt anything if you use one and then use another.
My preference is simply to use apache though - http is more firewall and internet friendly, it is also easier to hook into ldap or other authentication mechanisms, and you get features like webdav too. The performance may be less than svnserve, but its not particularly noticeable (the transferring of data across the network makes up the bulk of any performance issues)
If you need security for file transfers, then svnserve+ssh, or apache over https is your choice.
Check out FLOSS Weekly Episode 28. Greg Stein is one of the inventors of the WebDAV protocol for SVN and discusses the tradeoffs. My takeaway is that SVN: is faster but the http/webdav implementation is just fine for almost all purposes.
I've always used XInetD and HTTP.
HTTP also had WebDAV going on, so I could browse the source online if I wanted (or you can require a VPN if you wanted encryption and a dark-net type thing).
It really depends on what restrictions (if any) you're under.
Is it only going to be on a LAN? Will you need access outside of your LAN?
If so, will you have a VPN?
Do you have a static IP address and are you allowed to forward ports?
If you aren't under any restriction, I would then suggest going with xinetd (if you have xientd installed, daemon if you don't) and then (if you need remote access) use http-based server if you need remote access (you can also encrypt using HTTPS if you don't want plain text un/pw sent across).
Most other options are more effort with less benefit.
It's an SVN Repo -- you can always pack your bags and change things if you don't like it.
For ease of administration and security, we use svn+ssh for anything that requires commit access. We have set up HTTP based access for anonymous (read only) access to some open-source code, and it is much faster; the problem with svn+ssh is that it has to start up an ssh connection and a whole new svnserve for each user for every operation, which can get to be pretty slow after a while.
So, I'd recommend:
http for anonymous connections
svn+ssh if you need something secure and relatively quick and easy (assuming your users already have ssh set up and your users have access to the server)
https if you need something faster, secure, and you don't mind the extra overhead of administering it (or if you don't already have ssh set up or don't want to deal with Unix permissions)
I like sliksvn runs as a service in Windows, 2mins to setup and then forget about it.
It also comes with the client tools but download tortoise as well.
If you are going to be using the server only on the local machine and understand unix permissions, using file:// urls will be fast, simple and secure. Likewise, if you understand unix permissions and ssh and need to access it remotely, ssh will work great. While I see somebody else mentions it as "worst", I'm pretty sure that's simply due to the need to understand unix permissions.
If you do not like or understand unix permissions, you need to go with svnserve or http. I would probably choose to run it in xinetd, personally.
Finally, if you have firewall or proxy issues, you may need to consider using http. It's much more complicated, and i don't think you're going to see the benefits, so I'd put it last on your list.
I would recommend the http option, since I'm currently using svn+ssh and it appears to be the red-headed stepchild of the available protocols: 3rd-party tool support is consistently worse for svn+ssh than it is for http.
I've been responsible for administering both svnserve and Apache+SVN for my development teams, and I prefer the http-based solution for its flexibility. I know next to little about system administration, I'm a software guy after all, and I liked being able to hand authentication and authorization over to Apache.
Both tines the teams were about 10~15 people and both methods worked equally well. If you're planning for any expansion in the future, you might consider the http-based solution. It's just as easy to configure as svnserve, and if you're not going to expose the server to the Internet then you don't have to worry too much about securing and administering Apache either.
As a user of SVN, I prefer the http-based integration with Apache. I like being able to browse the repository with my web browser.
I am curious why NOT FSFS?? Important information - I am managing Windows systems.
I have done many projects with SVN and almost all of them were running from FSFS. Biggest repository was around 70GB (extreme), biggest ammount of repositories was around 700.
We never had any issues, even though we hosted it on Windows, NetApp and many other storage systems. Most of the time when I asked why NOT using FSFS only problem was that people simply didn't trust it.
Advantages:
No backend required (or dedicated server)
Fast and reliable
Hook scripts are supported
NTFS permissions are used
Easy to understand, easy to support, easy to manage
Disadvantages:
Not so easy access from outside your network (VPN)
Permissions only on repository-level (Read, Read/Write)
Hook scripts are running under current user credentials (which is sometimes advantage, sometimes disadvantage)
Martin