RDLogin: autologin using the pam.d service

[xabispacebiker]

I am trying to allow Rivendell login with LDAP so that users can login with their user account in RDAirplay but I cannot find any help to configure it correctly. I have read here and there that is possible but I couldn't make it work. Any help appreciated.

So far I have configured Rivendell to use the LDAP users and passwords, so now they can RDLogin using the LDAP account, but is it possible to do it automatically, so that when a user logins in the system, RDAirplay authenticates them too.

[alexolivan]

uuuuhhh ... didn't still though on that field, but now it caugh my attention!!! I didn't thought that was near as close! So, from what I read, someone, in some release of Rivendell, managed to integrate it with an LDAP service, is that correct?!?!

In my job, there's a department that sometimes deploy a windows-based radio automation system (In such cases my job consists on the streaming and audio IP-transport, that's how I came into the radio broadcasting world :-). The funny fact is that they can't integrate it in customer's domains!!! :-DDDDD , so, they suffer every MS-Windows cons, while they can't use/offer the (probably single) Windows pro: AD (... and customers seems to would really love RadioAutomation suite - AD integration)

Now I'm gonna step probably over the line ... does someone know of a Rivendell - Kerberos/LDAP Single Sign On success case?... Windows AD? Samba4? (I'm a sys/network admin/architecht, I can't avoid thinking that way)

Cheers!

[xabispacebiker]

Well so far I managed to enable LDAP authentication, but I have the following scenario: if user1 logs into Rivendell with his account, then logs out of the system and user2 logs into his Linux account and opens Rivendell, user 1 is still there open in Rivendell. We don't want that, at least user2 shouldn't be able to log into user1 Rivendell account without RdLogin first.

What we want is for user1 to log into his account and automatically, if there is a matching account in Rivendell, log into his Rivendell account, if the Rivendell user does not exist, use the default user.

[alexolivan]

oh... very interesting... I have not tried anything of this myself, but, just from memory recall... isn't there a way to 'RDLogout'?

I'm not sure now... Because, If so, Then I guess there should be a way to trigger an 'rdlogout' from system level (the place where that could be scripted is very dependant on the actual System/distro, somewhere in /etc/pam.d ... but in theory, should be possible to setup or modiy an existing script that would catch a logout sequence if [ "$PAM_TYPE" = "close_session" ]; then )

The key but, is to being able to 'rdlogout' someway... surely Fred could put dsome light here.

[xabispacebiker]

I'm not sure now... Because, If so, Then I guess there should be a way to trigger an 'rdlogout' from system level (the place where that could be scripted is very dependant on the actual System/distro, somewhere in /etc/pam.d ... but in theory, should be possible to setup or modiy an existing script that would catch a logout sequence if [ "$PAM_TYPE" = "close_session" ]; then )

Well, that's interesting.

By now I could sort it out by using a startup script on the users .profile:

# Login to Rivendell
/sbin/logintorivendell.sh

which does:

#!/bin/bash
DEF_FILE=/usr/local/etc/riv.cnf
WHOAMI=`whoami`
SERVER=MYSQL_SERVER
DB=Rivendell
HOSTNAME=$(mysql --defaults-file=$DEF_FILE --database=$DB -h $SERVER -sse "SELECT NAME FROM STATIONS WHERE NAME = '`hostname -f`' LIMIT 1;")
USER=$(mysql --defaults-file=$DEF_FILE --database=$DB -h $SERVER -sse "SELECT LOGIN_NAME FROM USERS WHERE LOGIN_NAME = '$WHOAMI' AND LOCAL_AUTH = 'Y' LIMIT 1;" )
if [ -z "$USER" ]; then
    USER="user" # Default user
fi
if [ ! -z "$HOSTNAME" ]; then
mysql --defaults-file=$DEF_FILE --database=$DB -h $SERVER <<EOF
UPDATE STATIONS SET USER_NAME = "$USER"
WHERE NAME = "$HOSTNAME" LIMIT 1;
EOF
fi

This is working really fine, but I'd prefer if there is a standard way of doing this.

[alexolivan]

Aha.... so you're kinda telling rivendell whos logged in by manually updating the 'station' table with the last, pamd/LDAP authenticated user at the login time... very interesting!

This but (I bet you already know) (messing with DB tables manually, besides the cli/gui modules) is something very 'hacky' , not for the faint of heart :-) ... don't try this at home :-D

[xabispacebiker]

I agree, that's why my last comment was I'd prefer if there was a standard way of doing this.. ;)

By now it is working (blessed linux scripting XD ) but of course, I'd rather find a standard way of doing this, meanwhile this hacky workaround works for my environment.

[ElvishArtisan]

While you haven't specifically mentioned it, I assume that the final goal is to authenticate Rivendell users via Active Directory? The "standard" way of doing this is to enable SSO (Single Sign On) at the OS level and then untick the 'Authenticate This User Locally' box in the user profile for those users that you want to authenticate AD. It's generally at Good Idea to leave at least one user configured to use local authentication in the event that AD becomes unavailable.

See this article for a rundown on how to configure SSO on RHEL/CentOS 7. Not simple unfortunately, but then nothing in AD ever is in my experience.

[alexolivan]

See this article for a rundown on how to configure SSO on RHEL/CentOS 7. Not simple unfortunately, but then nothing in AD ever is in my experience.

I have done several Debian - AD integration tests (that's now a quite mature thing...) that was not the problem... but:

untick the 'Authenticate This User Locally' box in the user profile for those users that you want to authenticate AD

I've read that right? you define users, untick that, and they're good to go? That's Awesome!!!!

[ElvishArtisan]

I've read that right? you define users, untick that, and they're good to go?

Correct,

[ElvishArtisan]

Or, to expand a bit ...

Unticking 'Authenticate This User Locally' will cause Rivendell to attempt to authenticate the specified user using the specified PAM service. The stock 'rivendell' one effectively asks the underlying OS "Is this user credential good, or not?".

But that's all that it does. No authorization handshakes --e.g. "Does this user have 'Edit Audio' permissions?"-- happen between Rivendell and the OS at all. Instead, Rivendell makes all of those determinations the usual way, by means of the '*_PRIV' fields in the USERS table. Hence, external users still need an appropriately provisioned entry in 'Manage Users'. The end result is that users can now manage their own passwords via AD.

[alexolivan]

The end result is that users can now manage their own passwords via AD.

Sure, sure .. I know what you mean :-) we're talking here about authentication (kerberos/LDAP, not authorization, AD storing permissions for 'MS environment' stuff on the LDAP domain objects...), and rhaving rivendell an authorization model on its own, it needs its own users to configure it, it logic ... But still, auth integration with AD is, for me, a completelly unexpected feature... I am very very impressed!!!

using the specified PAM service. The stock 'rivendell' one effectively asks the underlying OS

I asume 'stock' means out-of-the-box configuration for rivendell, isn'it? I mean it uses OS-level/System pam.d service out-of-the-box because default settings... but the 'stock' words make me think there'se some kind of further configuration for 'non-stock' needs... I feel I may have missed some part of the documentation, isn it?

Thank you!

[ElvishArtisan]

I asume 'stock' means out-of-the-box configuration for rivendell, isn'it? I mean it uses OS-level/System pam.d service out-of-the-box because default settings... but the 'stock' words make me think there'se some kind of further configuration for 'non-stock' needs... I feel I may have missed some part of the documentation, isn it?

It's 'stock' in the sense that it comes with the standard Rivendell software. See 'conf/rivendell.pam'. Pretty basic stuff.

[xabispacebiker]

Or, to expand a bit ...

Unticking 'Authenticate This User Locally' will cause Rivendell to attempt to authenticate the specified user using the specified PAM service. The stock 'rivendell' one effectively asks the underlying OS "Is this user credential good, or not?".

But that's all that it does. No authorization handshakes --e.g. "Does this user have 'Edit Audio' permissions?"-- happen between Rivendell and the OS at all. Instead, Rivendell makes all of those determinations the usual way, by means of the '*_PRIV' fields in the USERS table. Hence, external users still need an appropriately provisioned entry in 'Manage Users'. The end result is that users can now manage their own passwords via AD.

In relation to the original question, my system already logs against the LDAP server, what I want is not to have to use RDLogin to log in again to Rivendell, I'd like Rivendell to detect the user with whom I am logged in so that when I start RDAirplay or any other application I can use the (previously created) Rivendell user. If the logged in user does not exist in Rivendell database the use the default user.