How to identify if currently logged in user is an LDAP user in Solaris - ldap

I want to know how to identify if the currently logged in user in Solaris is a LDAP user or local user.
Any command?
or any C Run time functions like getspname, getpwnam which returns an attribute saying it is an LDAP user or local user after user logged in?

Ldaplist will tell you if the user has an entry in the ldap database. It doesn't sort out the case where the user has also an entry in the /etc/passwd file though.
ldaplist passwd username

I am assuming that UID's that are "local" are in separate range from "LDAP". I'm also assuming that nsswitch is configured to use files and ldap for passwd, shadow, and or group. The command 'getent' should be present on GNU libc systems. I'm going to assume that the local 'files' databases are smaller than ldap source and so we will want to test the smaller and / or faster of the two sources.
if you wanted to determine if a given UID was present one of the databses you could run somthing similar to
$ getent --service=files passwd | grep 655
This could match the the default GID in the file so a more creative grep may be in order.
$ getent --service=files passwd | grep -e $.*:.*:655
If you are looking to turn this into a script-able item, then you will want to tack 'wc' on the end to do integer testing.
$ getent --service=files passwd | grep -e $.*:.*:655 | wc -l
This should return 0 if not found, or 1 (or more) if found. We would only test one source because we are assuming that we are testing a valid UID and that it will be in the other source if its not in here.
Lastly, as long as you are using nsswitch you should be able to use any of the C Libraries that support this to check if they are valid. I don't have any first hand experience with them, but i would assume that you can pass an option like we did here to only use a specific source. Alternately you can use the same logic as above and just cat /etc/passwd. Assuming again that if they arn't in here they are in ldap.

It is not going to be easy. You can open the password file and look for them. If they aren't there, conclude LDAP. Unless, of course, it's NIS. Or Kerberos. If your version of Solaris has PAM you could read up on that to see if it has any relief to offer.

If you are using sss as part of the ipaclient package,
getent --service=sss passwd $USER | wc -l
will tell you if the user exists in the LDAP Database of the FreeIPA server.

I have no idea how to tell what credentials they used to actually authenticate, but it should be easier to just look them up in the LDAP database and see if they are there. I use the ldap_client utility to look people up all the time. You need to know the name of the ldap server, and a few other details. Check the man page for it. For example, if the user has a local account, and they are in LDAP, the passwords that get checked at login will depend on the system configuration.

Related

SQL permissions behaving unexpectedly

Recently I started learning php and sql because I have a fair bit of front end understanding, so I wanted to strengthen my understanding of back end systems. I bought a raspberry pi, and set up a simple LAMP server, which works great(ish). I can run php form it which is a good start.
However, I installed MariaDB v10.3.22 and I am having a lot of trouble with it. Upon successful installation, I went to log in, and expected a blank password. That didn't work.
mysql -u root -p
I get the error ERROR 1698 (28000): Access denied for user 'root'#'localhost' And because it was a fresh install I tried:
mysql_secure_installation
Anyway, I eventually found out that typing sudo mysql -u root -p would let me in, without a password at all. In fact even running the secure install with sudo made it work, meant I didn't need to enter a correct password. I could enter whatever password I wanted to get into the MariaDB shell and the secure script when running sudo, and it only worked with the root db user. Why is this? Why can sudo bypass all of this, especially because I haven't seen any use of sudo in the documentation.
I created a new user with full permissions and it works fine, I don't need sudo and the password actually works.
Sorry if this is confusing, but this is the best I can explain it because I am just as confused.
Thanks,
Angus
This may be due to the Unix Socket authentication plugin being used by the root user.
As the documentation for the plugin elaborates:
The unix_socket authentication plugin allows the user to use operating system credentials when connecting to MariaDB via the local Unix socket file.
The unix_socket authentication plugin works by calling the getsockopt system call with the SO_PEERCRED socket option, which allows it to retrieve the uid of the process that is connected to the socket. It is then able to get the user name associated with that uid. Once it has the user name, it will authenticate the connecting user as the MariaDB account that has the same user name.
Assuming that you aren't logged as root on your shell session, by running sudo mysql -u root -p you execute the command as root, and that's why you are not bypassing the authentication, it's just using the socket authentication as intended. It does not require a password since the OS user matches the MySQL user.
You can check if the root uses the Unix Socket authentication by doing the following:
MariaDB [(none)]> SELECT User, Host, plugin FROM mysql.user;
+------+-----------+-------------+
| User | Host | plugin |
+------+-----------+-------------+
| root | localhost | unix_socket |
+------+-----------+-------------+
I also suggest you to check this other question which addresses the same situation on MySQL.

Solaris/Unix password change in-line

I'm trying to change the root password on Solaris in a single command. So far I've tried:
echo "password" | passwd --stdin root
returns illegal option -- stdin on Solaris.
echo -e "password\npassword" | passwd root
Returns a 'New Password' prompt.
Using Solaris 10 and Bash 3.2.51 for the script.
You could do this via expect.
You could directly edit the /etc/shadow with sed or perl (of course you have to hash your password before, however as you want to hardcode it in your script you could use a different system, set the password manually copy it in your script and run the script of the target system. Or hash it on your own. is not that hard.
In solaris 11.3 starting with SRU4 there is a passwd -p to directly set the hash of the password. Would at least obfuscate the password by just putting the hash into the commandline.
But my real answer is:
Don't do it ... just don't do it. By setting the root password this way you essentially write a note with pink,blue and green marker around it with the root password in public for everyone who is on the system able to run ps in the moment you set the password. And this don't include the problem of management software putting ps outputs into central repositories and so put this information totally out of control of the system administrator.
Passwd doesn't read from STDIN, and there isn't an option, on Solaris, to read from STDIN.
A possible solution is to use an expect script
see: http://www.unix.com/solaris/161023-solaris-passwd-script.html

Run script as another user without sudo/su privileges

I'm trying to write a script so that it can be called by one user and is executed as another user. I thought that setuid might be able to do this so I enabled setuid using chmod u+s with the owner of the script being user1. I call the script (which only contains whoami right now) as user2 and it still shows user2 instead of user1. How can I make this be user1.
-- My end result is I want one user to be able to call this script and have it ssh into another server and execute a command as another user.
You can copy that user's key (id_rsa) and pass it to ssh when connecting to the server:
ssh -i user1_id_rsa user1#server
However, this is rather a bad solution, security-wise. Adding the user's key to the authorized keys on the server, as I said in the comment, is the proper way to do it, and you should really look into that.
Sounds like you need a third user in your security model, who can run the program, but is otherwise unprivileged. This third user is an assumable identity for a number of users so they can run the process on the remote server.

Is it possible to have a local group for an LDAP user

I have an LDAP server to which I do not have full privileges and an ubuntu system with LDAP authentication to which I am root. Is it possible to add an LDAP user to a local group?
(I don't know if I phrase this correctly but all I want is to have a user in LDAP in a group without editing the actual database)
Based on your answer it seems like what you needed was:
$ addgroup <group_name> (to make the group)
$ adduser -g <groupname> <username> (to add the user to the group)
OK silly me, just edited /etc/groups and worked

In Subversion can I be a user other than my login name?

I'd like to know how to get Subversion to change the name that my changes appear under.
I'm just starting to use Subversion. I'm currently using it to version control code on an XP laptop where I'm always logged in under my wife's name. I'd like the subversion DB to show the changes under my name.
Later on I'll replicate the DB so it is accessible to the whole house. My wife uses the office computer where she is always logged in under my name. I'll probably set it up so that it automatically checks in modified documents... preferably under her name.
Eventually I'll probably be using it from a linux machine under another username.
Is there some way to modify the user environment to change the user name that Subversion calls you? I'd expect something like setting SVN_USERNAME='Mark' which would override however it usually gets the name.
Update: It looks like the --username flag that Michael referred to does work to change the name reported by "svn stat", even for local file: repositories. In addition, it is sticky so you don't need to specify it for the next command. I even rebooted and it still used the "--username" value from my previous boot.
Most Subversion commands take the --username option to specify the username you want to use to the repository. Subversion remembers the last repository username and password used in each working copy, which means, among other things, that if you use svn checkout --username myuser you never need to specify the username again.
As Kamil Kisiel says, when Subversion is accessing the repository directly off the file system (that is, the repository URL is of form file:///path/to/repo or file://file-server/path/to/repo), it uses your file system permissions to access the repository. And when you connect via SSH tunneling (svn+ssh://server/path/to/repo), SVN uses your FS permissions on the server, as determined by your SSH login. In those cases, svn checkout --username may not work for your repository.
For svn over ssh try:
svn list svn+ssh://[user_name]#server_name/path_to_repo
svn will prompt you for the user_name's password.
You can setup a default username via ~/.subversion/servers:
[groups]
yourgroupname = svn.example.com
[yourgroupname]
username = yourusername
Please be aware that older versions of svn do not support it (e.g. 1.3.1 [sic!]).
"svn co --username=yourUserName --password=yourpassword http://path-to-your-svn"
Worked for me when on another user account. You will be prompted to enter username/password again though. You need to login like the above once and you are all set for the subsequent times(Unless you restart your machine).
If you need to specify a username other than your logged in user for use with svn+ssh just add an entry to your .ssh/config file:
Host example.com
User jdoe
Subversion usually asks me for my "Subversion username" if it fails using my logged in username. So, when I am lazy (usually) I'll just let it ask me for my password and I'll hit enter, and wait for the username prompt and use my Subversion username.
Otherwise, Michael's solution is a good way to specify the username right off.
Most of the answers seem to be for svn+ssh, or don't seem to work for us.
For http access, the easiest way to log out an SVN user from the command line is:
rm ~/.subversion/auth/svn.simple/*
Hat tip: http://www.yolinux.com/TUTORIALS/Subversion.html
Using Subversion with either the Apache module or svnserve. I've been able to perform operations as multiple users using --username.
Each time you invoke a Subversion command as a 'new' user, your $HOME/.subversion/auth/<authentication-method>/ directory will have a new entry cached for that user (assuming you are able to authenticate with the correct password or authentication method for the server you are contacting as that particular user).
I believe if you use the file:// method to access your subversion repository, your changes are always performed under the user which accesses the repository. You need to use a method that supports authentication such as http:// or svn://.
See http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.choosing
If you are using svn+ssh to connect to the repository then the only thing that authenticates you and authorizes you is your ssh credentials. EVERYTHING else is ignored. Your username will be logged in subversion exactly as it is established in your ssh connection. An excellent explanation of this is at jimmyg.org/blog/2007/subversion-over-svnssh-on-debian.html
Go to ~/.subversion/auth/svn.simple/*, and you will see a list of files that contains the information about your svn user account. Just delete all others that you don't need.
After that, when you do anything that regards to SVN operation, such as commit, rm, etc,. You will be prompt again to enter username or passwords.
TortoiseSVN always prompts for username. (unless you tell it not to)
I believe you can set the SVN_USER environment variable to change your SVN username.