Alexander, Simo,<div> </div><div>Thank you very much for this extensive explanation. I'll set it up monday and let you know how it will go.</div><div> </div><div>Fred</div><div> <div class="gmail_quote">On Sat, Oct 6, 2012 at 8:31 PM, Alexander Bokovoy <<a href="mailto:abokovoy@redhat.com" target="_blank">abokovoy@redhat.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, 06 Oct 2012, Fred van Zwieten wrote: >Hang on..I don't see how this can work (I haven't tried it btw). > >If I simply copy login to openvpn1 and call openvpn_auth_pam with that file >as a parameter, how can it magically know to query IPA for the openvpn1 >service as opposed to username/password? Must I not change the openvpn1 >file to have it check for the service? </div>PAM defines a 'service', equal to the name of /etc/pam.d/<service> file. An application using PAM starts using PAM functions by defining what service it will be, then PAM code load definitions of the service from the /etc/pam.d/<service> file and process them accordingly and apply them in appropriate stages (authentication, account management, session management, password checks). If your IPA hosts use SSSD daemon (default), then your PAM stack by default is configured to authenticate against IPA server and use of its features like Host-based access control (HBAC). You can verify it by checking /etc/pam.d/system-auth (login PAM service includes this file). Let's say, you want to define PAM services 'ovpn_group1' and 'ovpn_group2' that actually use login PAM service. You can do it following way: cd /etc/pam.d ln -s login ovpn_group1 ln -s login ovpn_group2 Now you have two configuration files named 'ovpn_group1' and 'ovpn_group2', you need to allow their use in both OpenVPN and in IPA to limit who can get into use of the service. On OpenVPN side you'd have two configuration files and set plugin openvpn-auth-pam.so ovpn_group1 in the first configuration file and plugin openvpn-auth-pam.so ovpn_group2 in the second. You don't need to add 'check_group' as the check would be done automatically by pam_sss module using HBAC rules from IPA. In IPA you can define HBAC services corresponding to those <service> files. We have predefined some of them, for commonly available on the machines, but you can expand that list. Go to 'Policy -> Host Base Acces Control -> HBAC Services' and add two services there, 'ovpn_group1' and 'ovpn_group2'. Next, define HBAC rules that reference the services ovpn_group1 and ovpn_group2. Put appropriate groups in the rules as to what users would be allowed to access them (and on which hosts). You need to be aware that IPA HBAC rules are explicit. If there is no rule that allows access, it is denied. By default there is one rule called 'allow_all' which is enabled, so access is allowed from any user to any service on any host. Once you start using explicit HBAC rules, you'll need to define all of them and then disable 'allow_all' rule because otherwise it will always match and grant access. Here is how this difference is visible. I defined one PAM service, 'test-service' by doing a symlink to login service file and used a simple program <a href="https://github.com/beatgammit/simple-pam/blob/master/src/test.c" target="_blank">https://github.com/beatgammit/simple-pam/blob/master/src/test.c</a> to test. The program simply initializes PAM stack for specified service ('check_user' in the source above, I only replaced that by 'test-service' in my copy) and then runs a sequence of calls, like any PAM-enabled application should do (except handling password expiration, but that is detail here). I have defined special HBAC rule in IPA that only allowed users from a group 'test' to use service 'test-service'. User admin does not belong to that group, user ab does belong to it. First with 'allow_all' rule enabled by default: -sh-4.2$ ./app admin Credentials accepted. Password: Account is valid. Authenticated -sh-4.2$ ./app ab Credentials accepted. Password: Account is valid. Authenticated -sh-4.2$ Now I disabled 'allow_all' rule in the IPA web UI: $ ./app admin Credentials accepted. Password: Account is valid. Not Authenticated -sh-4.2$ ./app ab Credentials accepted. Password: Account is valid. Authenticated -sh-4.2$ You'll see following in the /var/log/secure when 'allow_all' is disabled: ... Oct 6 21:16:06 head app: pam_sss(test-service:auth): authentication success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= user=admin Oct 6 21:16:06 head app: pam_sss(test-service:account): Access denied for user admin: 6 (Permission denied) ... Oct 6 21:17:43 head app: pam_unix(test-service:auth): authentication failure; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= user=ab Oct 6 21:17:46 head app: pam_sss(test-service:auth): authentication success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= user=ab Authentication went successfully (admin credentials were accepted) but then account management part of pam_sss applied HBAC rules and found out that none of the rules was matched, the access was denied. That's it, start your OpenVPN instances and they should be able to log-in only those users who pass HBAC rules for their specific PAM services. <div class="HOEnZb"><div class="h5"> >Fred > >> >> >> On Fri, Oct 5, 2012 at 9:09 PM, Simo Sorce <<a href="mailto:simo@redhat.com">simo@redhat.com</a>> wrote: >> >>> >>> Fred I suggest you copy the 'login' file into 2 new files: openvpn1 and >>> openvn2 >>> >>> Then configure the two instance instance with: >>> plugin openvpn_auth_pam openvpn1 >>> and >>> plugin openvpn_auth_pam openvpn2 >>> respectively. >>> >>> Then you can create HBAC rules in IPA using openvpn1 and openvon2 as >>> service names. >>> >>> Simo. >>> >>> On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: >>> > Dmitri, >>> > >>> > >>> > Well, this is, sort of, the point. I have no experience using pam, so >>> > I have no idea how to set this up. >>> > >>> > >>> > I have authentication up and running, but, like I said, both OpenVPN >>> > instances happily authenticate users from both groups of users. >>> > >>> > >>> > In my openvpn config file i have: >>> > >>> > >>> > plugin openvpn_auth_pam login >>> > >>> > >>> > where login is the /etc/pam.d/login file. I have not adjusted this >>> > file. This is standard file for IPA client. >>> > >>> > >>> > So, my idea was to do this in openvpn config file: >>> > >>> > >>> > plugin openvpn_auth_pam login (can the user authenticate y/n?) >>> > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is >>> > the user member op OPENVPN1 y/n?) >>> > >>> > >>> > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to >>> > authenticate against IPA. I am not sure how this could be setup to >>> > work with HBAC.. >>> > >>> > >>> > Fred >>> > >>> > >>> > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal <<a href="mailto:dpal@redhat.com">dpal@redhat.com</a>> wrote: >>> > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: >>> > > You are completely right :-) >>> > > >>> > > >>> > > Both IPA server and client are RHEL6.3 x86_64 boxes. >>> > > >>> > > >>> > > On the OpenVPN server (which is an IPA client), I have 2 >>> > > OpenVPN instances running, because different users must end >>> > > up in different subnet's >>> > > >>> > > >>> > > OpenVPN instance 1 listens on port 50000 >>> > > OpenVPN instance 2 listens on port 50001 >>> > > >>> > > >>> > > Users for subnet 1 must connect and authenticate on instance >>> > > 1 (and get an IP in subnet 1) >>> > > Users for subnet 2 must connect and authenticate on instance >>> > > 2 (and get an IP in subnet 2) >>> > > >>> > > >>> > > Both OpenVPN instances use the login pam module. >>> > > >>> > > >>> > > In this setup I can not prevent users for subnet 2 to >>> > > connect and authenticate successfully on OpenVPN instance 1. >>> > > >>> > > >>> > > So, I would like to put the users for OpenVPN instance 1 in >>> > > group OpenVPN1 en users for OpenVPN instance 2 in group >>> > > OpenVPN2 on IPA. >>> > > >>> > > >>> > > Next, the OpenVPN daemon must be able to check a user for >>> > > membership. Is it is not a member, false is returned, and >>> > > the OpenVMN authentication fails. >>> > > >>> > > >>> > > Documentation for the openvpn_auth_pam is here. >>> > > >>> > > >>> > >>> > >>> > OK, makes sense. >>> > How does you pam configuration look like? >>> > Especially the accounting part? What modules do you have >>> > there? >>> > Can it be PAM module you are using expecting some value that >>> > need to be configured in openvpn_auth_pam config? >>> > >>> > > Fred >>> > > >>> > > >>> > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal <<a href="mailto:dpal@redhat.com">dpal@redhat.com</a>> >>> > > wrote: >>> > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >>> > > > Hello, >>> > > > >>> > > > >>> > > > I have a IPA server running. This server has users >>> > > > who are member to various groups. I want to query >>> > > > the IPA server from an IPA client to know whether >>> > > > a user is a member to a group. >>> > > > >>> > > > >>> > > > I want to do this from the OpenVPN service using >>> > > > the openvpn_auth_pam.so. Normally one uses this >>> > > > like this: >>> > > > >>> > > > >>> > > > openvpn_auth_pam.so login >>> > > > >>> > > > >>> > > > This queries the PAM login (and thus IPA) is the >>> > > > username/password from openvpn is valid. the >>> > > > "login" is /etc/pam.d/login. OpenVPN docs say you >>> > > > could use other modules instead of login. >>> > > > >>> > > > >>> > > > So, I would like to add the next line: >>> > > > >>> > > > >>> > > > openvpn_auth_pam.so group <username> "openvpn" >>> > > > >>> > > > >>> > > > Where a /etc/pam.d/group file would check whether >>> > > > the user is member of the group "openvpn". If not, >>> > > > false is returned and the login attempt (thru >>> > > > openvpn) fails. >>> > > > >>> > > > >>> > > > Is this possible? If not is there a better way? >>> > > > >>> > > > >>> > > > Fred >>> > > >>> > > >>> > > >>> > > Can you step up from the implementation and explain >>> > > what you want to accomplish? >>> > > It seems that you want to use OpenVPN and do some >>> > > access control checks when user connects to OpenVPN. >>> > > Right? >>> > > If you can describe the flow of operations we might >>> > > be able guide you to the right solution. >>> > > >>> > > Also would be nice to understand what OS OpenVPN is >>> > > running on. >>> > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > _______________________________________________ >>> > > > Freeipa-users mailing list >>> > > > <a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> >>> > > > >>> <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> >>> > > >>> > > >>> > > -- >>> > > Thank you, >>> > > Dmitri Pal >>> > > >>> > > Sr. Engineering Manager for IdM portfolio >>> > > Red Hat Inc. >>> > > >>> > > >>> > > ------------------------------- >>> > > Looking to carve out IT costs? >>> > > <a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a> >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Freeipa-users mailing list >>> > > <a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> >>> > > <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> >>> > >>> > >>> > -- >>> > Thank you, >>> > Dmitri Pal >>> > >>> > Sr. Engineering Manager for IdM portfolio >>> > Red Hat Inc. >>> > >>> > >>> > ------------------------------- >>> > Looking to carve out IT costs? >>> > <a href="http://www.redhat.com/carveoutcosts/" target="_blank">www.redhat.com/carveoutcosts/</a> >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Freeipa-users mailing list >>> > <a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> >>> > <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >> >_______________________________________________ >Freeipa-users mailing list ><a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> ><a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a> -- </div></div>/ Alexander Bokovoy </blockquote></div> </div>