next »

[Saturn2888]

It would be nice to have eBox map Samba users and update the passwords and all with Unix users. This way programs like BackupPC can sync with it without having to go through some crazy LDAP users in Apache2 Kerobos thing. The users don't even have to have hardly any rights.

I could see this as a module which you install, and it says "users have access to modules blah" or something. For my own personal reasons, I just want them to be able to login to the BackupPC web interface. Maybe there's a better way of doing this. In most cases, I'm assuming this is what others want as well especially companies that do things using online systems.

It could be a lot easier on LDAP too if the Samba users were as Unix users and you needed to upgrade the module or purge it for whatever reason because when it comes back, it'd be neat to have an option to upload your users that were deleted in the purge. Maybe a way to backup and restore users is better.

[Saturn2888]

This feature has been enabled in Office > Users & Groups > LDAP Settings > PAM settings area. The checkbox's intended purpose states: "Make LDAP users have system account."

[Saturn2888]

I might want to note, this only works if the machine has eBox 1.5+ and if it's the Master. I configured a 1.4 machine as the Master and the option disappeared.

[sixstone]

Yes, Saturn2888.

This feature is a brand new one in eBox 2.0 .

Best,

[Kamilion]

Just what I needed! I'll have a look at it soon.

[Saturn2888]

Next step is to make Unix users available in Apache2, haha.

[christian]

As discussed in another thread, difference between "unix" users and "non unix" users can be very tiny if NSS is used.
i.e. almost all users (except root for obvious reason) could be defined in LDAP as unix users and seen through NSS_ldap if, e.g. passwd is defined with "file + ldap".

One way to look at this could be (but I'm not sure this is current eBox philosophy) to store all accounts except root and ebox (plus few others) in LDAP  and grant some of these account for Samba attributes when such accounts are authorized to use Samba service.
Same for email and any other service requiring specific attribute.

[sixstone]

Hi Christian,

One way to look at this could be (but I'm not sure this is current eBox philosophy) to store all accounts except root and ebox (plus few others) in LDAP  and grant some of these account for Samba attributes when such accounts are authorized to use Samba service.
Same for email and any other service requiring specific attribute.

We cannot rely on OpenLDAP to manage users accounts, at least, at first stages since we do not have ebox-usersandgroups as base package.

The only way to do it for the sysadmin, is to have a single account to admin the system through SSH and have all users in LDAP if you want. Then with that feature, you may share it if you need to use system users for any service. But this is less important now, since we have ebox-ftp now integrated with eBox using LDAP stored users.

Best,

[Saturn2888]

This is less important now, since we have ebox-ftp now integrated with eBox using LDAP stored users.

Can you add in ebox-webserver into that list too please? Haha. I've just been looking for a better method of putting LDAP users able to authenticate to Apache2 websites which are not eBox is all. If I was a business and had some kinda online database, I'd like it to be only the users I already had that could access that database from the webserver, not some other user management system. That's just me though. I consider this a selfish request.

[Kamilion]

Okay, I've had a tinker with this -- needed some slight tweaks for me.

EDIT: MAJOR TIP: 'sudo apt-get install ldapvi'
then run /usr/share/ebox-usersandgroups/ebox-ldapvi
Now you can edit your LDAP database with nano! (Even works on 1.4!)



Turned on the Enable PAM checkbox.

Oh oh, first problem, default shells are /bin/false! Easy fix:
change /etc/ebox/80users.conf:

Code:

# default login shell for users
login_shell = /bin/bash

Okay, now everything works.

First off, using /bin/false as the default shell is broken: sftp-server doesn't work, and using ssh -N still lets you in; which means you can port forward or SOCKS forward without issue:

Code:

kamilion@SmallBlock:~$ ssh -vN -D1080 kamilion@ebox.domain.com
OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to ebox.domain.com [10.10.10.10] port 22.
debug1: Connection established.
debug1: identity file /home/kamilion/.ssh/identity type -1
debug1: identity file /home/kamilion/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-4096
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-4096
debug1: identity file /home/kamilion/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu4
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu4 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'ebox.domain.com' is known and matches the RSA host key.
debug1: Found key in /home/kamilion/.ssh/known_hosts:37
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/kamilion/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 533
debug1: Authentication succeeded (publickey).
debug1: Local connections to LOCALHOST:1080 forwarded to remote address socks:0
debug1: Local forwarding listening on ::1 port 1080.
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 1080.
debug1: channel 1: new [port listener]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.

^Cdebug1: channel 0: free: port listener, nchannels 2
debug1: channel 1: free: port listener, nchannels 1
debug1: Killed by signal 2.
kamilion@SmallBlock:~$

http://www.semicomplete.com/articles/ssh-security/

The better way to deal with this is to create a shelluser group, and then edit /etc/ssh/sshd_config and add an 'AllowGroups shelluser root' directive. (NOTE: you must use the name of users or groups; not the id.)

Code:

Jul 29 20:31:03 hub sshd[14430]: User arshad from 10.10.10.10 not allowed because none of user's groups are listed in AllowGroups

Jul 29 20:31:12 hub sshd[14432]: Accepted publickey for kamilion from 10.10.10.10 port 51125 ssh2
Jul 29 20:31:12 hub sshd[14432]: pam_unix(sshd:session): session opened for user kamilion by (uid=0)
Jul 29 20:31:16 hub sshd[14506]: Received disconnect from 10.10.10.10: 11: disconnected by user
Jul 29 20:31:16 hub sshd[14432]: pam_unix(sshd:session): session closed for user kamilion

Jul 29 20:31:22 hub sshd[14521]: Accepted publickey for root from 10.10.10.10 port 51126 ssh2
Jul 29 20:31:22 hub sshd[14521]: pam_unix(sshd:session): session opened for user root by (uid=0)
Jul 29 20:31:28 hub sshd[14521]: Received disconnect from 10.10.10.10: 11: disconnected by user
Jul 29 20:31:28 hub sshd[14521]: pam_unix(sshd:session): session closed for user root

http://www.cyberciti.biz/tips/openssh-deny-or-restrict-access-to-users-and-groups.html

Alternatively, you could go even further and do the job properly the first time: ask PAM to allow/deny from a listfile like /etc/ssh/sshd.deny

like:

Code:

auth required pam_listfile.so item=user sense=deny file=/etc/ssh/sshd.deny onerr=succeed

or:

Code:

auth required pam_listfile.so item=user sense=allow file=/etc/ssh/sshd.allow onerr=fail

http://www.cyberciti.biz/tips/linux-pam-configuration-that-allows-or-deny-login-via-the-sshd-server.html

[Oceanwatcher]

Thread edited to remove subject prefix.