Oracle will require you to configure the Oracle RDBMS to use operating system authentication but if you inherit an Oracle instance, you will want to disable os authentication when possible. When the OS_AUTHENT_PREFIX is set, any os user that is created with “IDENTIFIED EXTERNALLY” will have the prefix. For example, in the below example, the value is “ops$”. The os user johnnybgood will have an internal Oracle user id of “ops$johnnybgood”. It’s a handy way to quickly identify such users but it isn’t full proof.
show parameter OS_AUTHENT_PREFIX
lang-NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
os_authent_prefix string ops$
To determine exactly which users are set up for os authentication run the following query:
set pagesize 5000
set linesize 999
set trimspool on
select gn.GLOBAL_NAME as "Instance", username, authentication_type
from dba_users du, global_name gn
where authentication_type = 'EXTERNAL'
Now, there are valid reasons to use os authentication but I would push LDAP long before os authentication.
From the Oracle Security Admin Guide:
Advantages of External Authentication
Following are the advantages of external authentication:
More choices of authentication mechanism are available, such as smart cards, fingerprints, Kerberos, or the operating system.
Many network authentication services, such as Kerberos support single sign-on, enabling users to have fewer passwords to remember.
If you are already using some external mechanism for authentication, such as one of those listed earlier, then there may be less administrative overhead to use that mechanism with the database as well.
I rebuilt an Ubuntu 9.10 server this past week, ripping off VMware and replacing it with VirtualBox 3.1.2. Setting up VirtualBox as a headless server was very easy with VBoxTool. However, I ran into a problem that I was unable to connect using remote desktop (rdesktop) as any user but the user that started the virtual machine.
Jan 21 22:43:13 vm-holder unix_chkpwd: check pass; user unknown
Jan 21 22:43:13 vm-holder unix_chkpwd: password check failed for user (jason)
Jan 21 22:43:13 vm-holder VBoxHeadless: pam_unix(vrdpauth:auth): authentication failure; logname=virtualbox uid=1001 euid=1001 tty= ruser= rhost= user=jason
This is, currently, an undocumented security feature of VirtualBox 3.1x to prevent just anyone from accessing the virtual machine console. For most folk, this might be a very good thing but if you have a team of sysadmins that should have access to the virtual machine consoles, you probably don’t want them to use the same login.
If that is the case, you can add the user(s) that should have access the virtual machine console to the shadow group on the host Linux machine. Be warned though that the user(s) that are added to the shadow group should not be able to log into the host machine else they will be able to read the shadow file where all the passwords to the box are stored. If the users need access to the host box, then they should have a login for host access (not part of the shadow group) and another for virtual machine console access.
Adding linux user jason_vrdp to the shadow group:
(root) # usermod -G shadow,virtualbox jason_vrdp
Prevent jason_vrdp from logging in to the host or anyone from sudo’ing to it:
(root) # usermod --shell /bin/false jason_vrdp
That’s it 🙂
Here’s the scenario:
You ssh to a remote server with your login and either sudo or su to another user to run some application that uses a X Windows front end. There is a firewall between your desktop and the remote server that allows only ssh connections (port 22). When you run into the error “Xlib: PuTTY X11 proxy: wrong authentication protocol attempted”. What to do?
ssh jason@remote-server -X
jason $ echo $DISPLAY
jason $ su - oracle
oracle $ xterm
Xlib: connection to "localhost:10.0" refused by server
Xlib: PuTTY X11 proxy: wrong authentication protocol attempted
xterm Xt error: Can't open display: localhost:10.0
On recent OpenSSH Server releases, you can simply enable “ForwardX11Trusted yes” in the /etc/ssh/sshd_config file and restart the OpenSSH server. If you’re not using a recent OpenSSH Server release or if you can’t for security or political reasons, what could you do? Give up? It’s simpler than you think.
You need to temporarily transfer the authorization to the other account. First, get the key from your account:
jason $ xauth list
aspc2o1/unix:10 MIT-MAGIC-COOKIE-1 bc334c66cfec3c5c3d5b0efc4ee9d3ad
Next, sudo/su to the other account and add the authorization key.
jason $ su - oracle
oracle $ xauth add aspc2o1/unix:10 MIT-MAGIC-COOKIE-1 bc334c66cfec3c5c3d5b0efc4ee9d3ad
Now, you should be able to start any X Windows application, assuming that your DISPLAY variable is set to go through the ssh tunnel:
oracle $ xterm
Kyle McBride provided an easy way to automate adding the key to xauth. Add the following to your .bashrc or .profile file.
xauth list | while read x ; do sudo -u oracle xauth add $x ; done
The -u oracle will run the xauth command as the user oracle otherwise the keys will be added to the root user.