Re: [Freeipa-users] feature request
Dmitri Pal wrote: > On 07/20/2014 06:37 PM, Rob Crittenden wrote: >> sergey ivanov wrote: >>> Dear IPA developers, I'd like to describe what we are doing and ask >>> about existing ways to do it easier, or if there is no such ways - to >>> propose creating some tools to ease such way of migration. >>> >>> We are preparing for migration to IPA. In our organization we were >>> using kerberos servers for authentication together with /etc/passwd >>> files for managing user access to hosts. In our organization we also >>> are using kerberos together with .htacces files for web >>> authentication. And kerberos with pam for mail services, - both IMAP >>> and SMTP via dovecot. >>> >>> I asked some time ago and got reply here in this mailing list, that >>> there is no way to use kdb_util to dump kerberos database and get from >>> the dump values for inserting into IPA's ldap kerberos principle >>> fields for user entries. So, we ended up using special web page, which >>> authenticate our users against existing kerberos servers and after >>> successful authentication reset password for this user in IPA. >>> >>> We did not want password in IPA to be in "expired" state, so that >>> users must change once more at first login. As a workaround we are >>> using 2 different kerberos connection caches for each session: one for >>> administrator for setting up user password to something unique, and >>> second - for authenticating with this unique password as a user, just >>> to reset it to the value he requested by user though web form. >>> >>> I think there would be pretty many similar cases. May be having >>> customizable web form on IPA server itself, authenticating for user >>> against some old external authentication system from which the >>> migration is being performed would be the best. >>> >>> If not, than at least some standard way to drop privileges from >>> administrator to user, for setting up password or maybe even other >>> fields, would be great. >>> >> I take it that the LDAP connection used by your migration page isn't >> using the credentials provided by the user, but binding using some >> service account? Binding as the user would be ideal, but if you can't >> you can add the dn for that service account dn to the >> passSyncManagersDNs list to have it not cause a reset. >> >> % ldapmodify -x -D "cn=Directory Manager" -W >> Enter LDAP Password: *** >> dn: cn=ipa_pwd_extop,cn=plugins,cn=config >> changetype: modify >> add: passSyncManagersDNs >> passSyncManagersDNs: uid=webadmin,cn=users,cn=accounts,dc=example,dc=com >> >> rob >> > Should we turn it into HOWTO? I believe this is already in the documentation. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] feature request
On 07/20/2014 06:37 PM, Rob Crittenden wrote: sergey ivanov wrote: Dear IPA developers, I'd like to describe what we are doing and ask about existing ways to do it easier, or if there is no such ways - to propose creating some tools to ease such way of migration. We are preparing for migration to IPA. In our organization we were using kerberos servers for authentication together with /etc/passwd files for managing user access to hosts. In our organization we also are using kerberos together with .htacces files for web authentication. And kerberos with pam for mail services, - both IMAP and SMTP via dovecot. I asked some time ago and got reply here in this mailing list, that there is no way to use kdb_util to dump kerberos database and get from the dump values for inserting into IPA's ldap kerberos principle fields for user entries. So, we ended up using special web page, which authenticate our users against existing kerberos servers and after successful authentication reset password for this user in IPA. We did not want password in IPA to be in "expired" state, so that users must change once more at first login. As a workaround we are using 2 different kerberos connection caches for each session: one for administrator for setting up user password to something unique, and second - for authenticating with this unique password as a user, just to reset it to the value he requested by user though web form. I think there would be pretty many similar cases. May be having customizable web form on IPA server itself, authenticating for user against some old external authentication system from which the migration is being performed would be the best. If not, than at least some standard way to drop privileges from administrator to user, for setting up password or maybe even other fields, would be great. I take it that the LDAP connection used by your migration page isn't using the credentials provided by the user, but binding using some service account? Binding as the user would be ideal, but if you can't you can add the dn for that service account dn to the passSyncManagersDNs list to have it not cause a reset. % ldapmodify -x -D "cn=Directory Manager" -W Enter LDAP Password: *** dn: cn=ipa_pwd_extop,cn=plugins,cn=config changetype: modify add: passSyncManagersDNs passSyncManagersDNs: uid=webadmin,cn=users,cn=accounts,dc=example,dc=com rob Should we turn it into HOWTO? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] feature request
sergey ivanov wrote: > Dear IPA developers, I'd like to describe what we are doing and ask > about existing ways to do it easier, or if there is no such ways - to > propose creating some tools to ease such way of migration. > > We are preparing for migration to IPA. In our organization we were > using kerberos servers for authentication together with /etc/passwd > files for managing user access to hosts. In our organization we also > are using kerberos together with .htacces files for web > authentication. And kerberos with pam for mail services, - both IMAP > and SMTP via dovecot. > > I asked some time ago and got reply here in this mailing list, that > there is no way to use kdb_util to dump kerberos database and get from > the dump values for inserting into IPA's ldap kerberos principle > fields for user entries. So, we ended up using special web page, which > authenticate our users against existing kerberos servers and after > successful authentication reset password for this user in IPA. > > We did not want password in IPA to be in "expired" state, so that > users must change once more at first login. As a workaround we are > using 2 different kerberos connection caches for each session: one for > administrator for setting up user password to something unique, and > second - for authenticating with this unique password as a user, just > to reset it to the value he requested by user though web form. > > I think there would be pretty many similar cases. May be having > customizable web form on IPA server itself, authenticating for user > against some old external authentication system from which the > migration is being performed would be the best. > > If not, than at least some standard way to drop privileges from > administrator to user, for setting up password or maybe even other > fields, would be great. > I take it that the LDAP connection used by your migration page isn't using the credentials provided by the user, but binding using some service account? Binding as the user would be ideal, but if you can't you can add the dn for that service account dn to the passSyncManagersDNs list to have it not cause a reset. % ldapmodify -x -D "cn=Directory Manager" -W Enter LDAP Password: *** dn: cn=ipa_pwd_extop,cn=plugins,cn=config changetype: modify add: passSyncManagersDNs passSyncManagersDNs: uid=webadmin,cn=users,cn=accounts,dc=example,dc=com rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] feature request
Dear IPA developers, I'd like to describe what we are doing and ask about existing ways to do it easier, or if there is no such ways - to propose creating some tools to ease such way of migration. We are preparing for migration to IPA. In our organization we were using kerberos servers for authentication together with /etc/passwd files for managing user access to hosts. In our organization we also are using kerberos together with .htacces files for web authentication. And kerberos with pam for mail services, - both IMAP and SMTP via dovecot. I asked some time ago and got reply here in this mailing list, that there is no way to use kdb_util to dump kerberos database and get from the dump values for inserting into IPA's ldap kerberos principle fields for user entries. So, we ended up using special web page, which authenticate our users against existing kerberos servers and after successful authentication reset password for this user in IPA. We did not want password in IPA to be in "expired" state, so that users must change once more at first login. As a workaround we are using 2 different kerberos connection caches for each session: one for administrator for setting up user password to something unique, and second - for authenticating with this unique password as a user, just to reset it to the value he requested by user though web form. I think there would be pretty many similar cases. May be having customizable web form on IPA server itself, authenticating for user against some old external authentication system from which the migration is being performed would be the best. If not, than at least some standard way to drop privileges from administrator to user, for setting up password or maybe even other fields, would be great. -- Regards, Sergey Ivanov | serge...@gmail.com http://www.linkedin.com/pub/sergey-ivanov/8/270/a09 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] [Feature request] Adding support for sudo to ipa-client-install
On Thu, Feb 21, 2013 at 03:07:10PM +0100, Han Boetes wrote: > This is what you have to do to enable sudo support while using freeipa: I > got it all from > sssd-sudo(5). > > # yum install libsss_sudo > > Add this line to /etc/nsswitch.conf > > sudoers: files sss > > Edit /etc/sssd/sssd.conf and make the following changes: > > Add sudo to the "services =" line. > > And add lines like these to the [domain/example.com] section > >sudo_provider = ldap >ldap_uri = ldap://ipa.example.com >ldap_sudo_search_base = ou=sudoers,dc=example,dc=com >ldap_sasl_mech = GSSAPI >ldap_sasl_authid = host/hostname.example.com >ldap_sasl_realm = EXAMPLE.COM >krb5_server = ipa.example.com > > And after that sudo should work. For debugging stop the sssd service and > run sssd with the following options: > > /usr/sbin/sssd -D -f -d4 > > And then tail /var/log/sssd/sssd_example.com.log > > My request to the freeipa developers is to add an option to > ipa-install-client script to support these changes. Perhaps even make it > the default since it's so nice and useful to have. > > > > # Han There is already https://fedorahosted.org/freeipa/ticket/3358 open which is tracking the exact use case. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request
On 02/24/2012 01:59 PM, Dan Scott wrote: On Fri, Feb 24, 2012 at 15:48, Rich Megginson wrote: On 02/24/2012 01:34 PM, Dan Scott wrote: On Fri, Feb 24, 2012 at 13:43, Rob Crittendenwrote: Dan Scott wrote: Hi, I have an idea for a new feature. I've been having a lot of problems with replication recently and I think the following would be useful. Can we show the replication status of the masters/replicas? And also show whether they contain a CA? Something like: ipa-replica-manage -v list server1.example.com: master,CA [Up-to-date] server2.example.com: master,CA [Not replicating!] server3.example.com: master [Up-to-date] Add a server name to the end of that command and you'll get the status: # ipa-replica-manage list -v rawhide.greyoak.com Directory Manager password: pony.greyoak.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-02-24 18:12:59+00:00 win2003.greyoak.com: replica last init status: 0 Total update succeeded last init ended: 2012-02-24 18:07:26+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-02-24 18:37:25+00:00 Excellent! Thanks. Unfortunately, I have a problem: [root@fileserver1 ~]# ipa-replica-manage -v list fileserver1 fileserver2: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionSystem error last update ended: 2012-02-15 22:02:39+00:00 fileserver4: replica last init status: 0 Total update succeeded last init ended: 2012-02-24 18:13:51+00:00 last update status: -1 - System error last update ended: 2012-02-24 18:09:22+00:00 Neither of those look good :( Any ideas to solve the problems? I would suggest upgrading to 389-ds-base-1.2.10.2 - then we can investigate further When I updated Fedora last week on one of my replicas, it completely killed my LDAP server. I sent another mail to the list about this. There are known crashing issues in 389-ds-base before 1.2.10.2 Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request
On Fri, Feb 24, 2012 at 15:48, Rich Megginson wrote: > On 02/24/2012 01:34 PM, Dan Scott wrote: >> >> On Fri, Feb 24, 2012 at 13:43, Rob Crittenden wrote: >>> >>> Dan Scott wrote: Hi, I have an idea for a new feature. I've been having a lot of problems with replication recently and I think the following would be useful. Can we show the replication status of the masters/replicas? And also show whether they contain a CA? Something like: ipa-replica-manage -v list server1.example.com: master,CA [Up-to-date] server2.example.com: master,CA [Not replicating!] server3.example.com: master [Up-to-date] >>> >>> >>> Add a server name to the end of that command and you'll get the status: >>> >>> # ipa-replica-manage list -v rawhide.greyoak.com >>> Directory Manager password: >>> >>> pony.greyoak.com: replica >>> last init status: None >>> last init ended: None >>> last update status: 0 Replica acquired successfully: Incremental update >>> succeeded >>> last update ended: 2012-02-24 18:12:59+00:00 >>> win2003.greyoak.com: replica >>> last init status: 0 Total update succeeded >>> last init ended: 2012-02-24 18:07:26+00:00 >>> last update status: 0 Replica acquired successfully: Incremental update >>> succeeded >>> last update ended: 2012-02-24 18:37:25+00:00 >> >> Excellent! Thanks. Unfortunately, I have a problem: >> >> [root@fileserver1 ~]# ipa-replica-manage -v list fileserver1 >> fileserver2: replica >> last init status: None >> last init ended: None >> last update status: -1 Incremental update has failed and requires >> administrator actionSystem error >> last update ended: 2012-02-15 22:02:39+00:00 >> fileserver4: replica >> last init status: 0 Total update succeeded >> last init ended: 2012-02-24 18:13:51+00:00 >> last update status: -1 - System error >> last update ended: 2012-02-24 18:09:22+00:00 >> >> Neither of those look good :( Any ideas to solve the problems? > > I would suggest upgrading to 389-ds-base-1.2.10.2 - then we can investigate > further When I updated Fedora last week on one of my replicas, it completely killed my LDAP server. I sent another mail to the list about this. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request
On 02/24/2012 01:34 PM, Dan Scott wrote: On Fri, Feb 24, 2012 at 13:43, Rob Crittenden wrote: Dan Scott wrote: Hi, I have an idea for a new feature. I've been having a lot of problems with replication recently and I think the following would be useful. Can we show the replication status of the masters/replicas? And also show whether they contain a CA? Something like: ipa-replica-manage -v list server1.example.com: master,CA [Up-to-date] server2.example.com: master,CA [Not replicating!] server3.example.com: master [Up-to-date] Add a server name to the end of that command and you'll get the status: # ipa-replica-manage list -v rawhide.greyoak.com Directory Manager password: pony.greyoak.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-02-24 18:12:59+00:00 win2003.greyoak.com: replica last init status: 0 Total update succeeded last init ended: 2012-02-24 18:07:26+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-02-24 18:37:25+00:00 Excellent! Thanks. Unfortunately, I have a problem: [root@fileserver1 ~]# ipa-replica-manage -v list fileserver1 fileserver2: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionSystem error last update ended: 2012-02-15 22:02:39+00:00 fileserver4: replica last init status: 0 Total update succeeded last init ended: 2012-02-24 18:13:51+00:00 last update status: -1 - System error last update ended: 2012-02-24 18:09:22+00:00 Neither of those look good :( Any ideas to solve the problems? I would suggest upgrading to 389-ds-base-1.2.10.2 - then we can investigate further Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request
On Fri, Feb 24, 2012 at 13:43, Rob Crittenden wrote: > Dan Scott wrote: >> >> Hi, >> >> I have an idea for a new feature. I've been having a lot of problems >> with replication recently and I think the following would be useful. >> >> Can we show the replication status of the masters/replicas? And also >> show whether they contain a CA? >> >> Something like: >> >> ipa-replica-manage -v list >> >> server1.example.com: master,CA [Up-to-date] >> server2.example.com: master,CA [Not replicating!] >> server3.example.com: master [Up-to-date] > > > Add a server name to the end of that command and you'll get the status: > > # ipa-replica-manage list -v rawhide.greyoak.com > Directory Manager password: > > pony.greyoak.com: replica > last init status: None > last init ended: None > last update status: 0 Replica acquired successfully: Incremental update > succeeded > last update ended: 2012-02-24 18:12:59+00:00 > win2003.greyoak.com: replica > last init status: 0 Total update succeeded > last init ended: 2012-02-24 18:07:26+00:00 > last update status: 0 Replica acquired successfully: Incremental update > succeeded > last update ended: 2012-02-24 18:37:25+00:00 Excellent! Thanks. Unfortunately, I have a problem: [root@fileserver1 ~]# ipa-replica-manage -v list fileserver1 fileserver2: replica last init status: None last init ended: None last update status: -1 Incremental update has failed and requires administrator actionSystem error last update ended: 2012-02-15 22:02:39+00:00 fileserver4: replica last init status: 0 Total update succeeded last init ended: 2012-02-24 18:13:51+00:00 last update status: -1 - System error last update ended: 2012-02-24 18:09:22+00:00 Neither of those look good :( Any ideas to solve the problems? Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request
Dan Scott wrote: Hi, I have an idea for a new feature. I've been having a lot of problems with replication recently and I think the following would be useful. Can we show the replication status of the masters/replicas? And also show whether they contain a CA? Something like: ipa-replica-manage -v list server1.example.com: master,CA [Up-to-date] server2.example.com: master,CA [Not replicating!] server3.example.com: master [Up-to-date] Add a server name to the end of that command and you'll get the status: # ipa-replica-manage list -v rawhide.greyoak.com Directory Manager password: pony.greyoak.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-02-24 18:12:59+00:00 win2003.greyoak.com: replica last init status: 0 Total update succeeded last init ended: 2012-02-24 18:07:26+00:00 last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2012-02-24 18:37:25+00:00 Some of the recent updates to IPA have caused replication problems for me. The first that I know about it is when I start getting weird problems like inconsistent results from user lookups, etc. Or when users start complaining. This would be a useful way to get the overall status of my IPA servers. I would also like a related feature which would check the servers remotely to ensure that the required services are running. i.e. Test that I can get a kerberos ticket, perform an LDAP lookup, the CA is working, etc. ipactl status will at least make sure the processes are running. Only works on the local box though. I filed RFE https://fedorahosted.org/freeipa/ticket/2443 for the rest. regards rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Feature request
Hi, I have an idea for a new feature. I've been having a lot of problems with replication recently and I think the following would be useful. Can we show the replication status of the masters/replicas? And also show whether they contain a CA? Something like: ipa-replica-manage -v list server1.example.com: master,CA [Up-to-date] server2.example.com: master,CA [Not replicating!] server3.example.com: master [Up-to-date] Some of the recent updates to IPA have caused replication problems for me. The first that I know about it is when I start getting weird problems like inconsistent results from user lookups, etc. Or when users start complaining. This would be a useful way to get the overall status of my IPA servers. I would also like a related feature which would check the servers remotely to ensure that the required services are running. i.e. Test that I can get a kerberos ticket, perform an LDAP lookup, the CA is working, etc. Thanks, Dan ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
James Roman wrote:
>
> From what I can see it looks like the missing piece would be the ability
> to look up tac_plus user->group assignments from the FreeIPA/389 LDAP
> server. It looks like tac_plus has ""integrated"" the authentication
> with LDAP via PAM, but not the authorization. When building an
> authentication solution for network devices with FreeIPA, providing
> authentication via TACACS+ would be secondary, since you could have your
> Cisco device directly authenticate the user against FreeIPA using
> Kerberos. TACACS+ primary benefit is in the granular control of
> Authorization to network device services. If you can get tac_plus to
> reference an LDAP server for group membership, then you might have a
> reasonable solution. You would still need to assign the group's network
> permissions in the tac_plus configuration file, but that would be done
> once. Once the group access was defined, you could assign LDAP users to
> groups that match what's in the tac_plus config file.
>
> This really requires the tac_plus team to code direct LDAP integration
> into their application similar to the way Freeradius can rely on an LDAP
> server as a back-end. The local PAM stack was not really intended to be
> a service that can be farmed out for other systems to use. It was meant
> as a way to provide access to local services running on that system. To
> use PAM for group membership (I.E. through the pam_listfile ACL) would
> require a separate tac_plus daemon and PAM configuration for each
> network device.
Yep. We're using tac_plus from shrubbery and have configured it for pam
auth for login (they've intentionally not allowed pam auth for enable
access). It would be nice to not have to worry about enumerating users
in the tac_plus configuration and pull data out of LDAP though that
seems more to be a feature request against tac_plus than IPA. We're
also using freeradius2 with LDAP auth (via pam) mostly to support a
Cisco NCM installation because the Tacacs+ support in the current
version of NCM is broken and fails to authenticate users if their
password is >15 characters, but I digress. Some future integration of
tacacs+ configuration with freeipa would be nice allowing for management
via the web management interface, though I think as has been stated, the
first step may be more to get the tac_plus code to look for particular
group memberships. Our current user definitions are simply in the form:
user = someuser {
member = some_group
}
with the one time effort of setting up the groups.
Kambiz
--
"All tyranny needs to gain a foothold is for people of
good conscience to remain silent." --Thomas Jefferson
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
James Roman wrote: > >>> >>> From both a network and a security point of view, TACACS+ is >>> considered preferable to RADIUS; among other benefits, it enciphers >>> the entire conversation, rather than just portions of it, and can >>> provide more fine-grain authorization than RADIUS. Most Cisco shops >>> I've encountered consider RADIUS to be an unacceptable solution for >>> AAA. Cisco considers use of TACACS+ a best practice for AAA. >>> >>> What I am looking for is a device on the network which provides AAA >>> facilities to network infrastructure devices, and which allows >>> provisioning of network infrastructure credentials through the same >>> interface and at the same time as systems credentials, and which keeps >>> those credentials synchronized. >>> >> >> O.K. fair enough. However TACACS is not on our roadmap. If you can >> demonstrate strong need by enterprise customers for TACACS it would >> be taken into consideration for a future version of the product. >> >> The more practical solution which may be available to you would be to >> avail yourself of the PAM integration in the tac_plus project (but to >> be honest I don't see how that would give you any of the >> sophisticated features you cite as being a prime motivator for >> utilization of TACACS). FreeIPA is an open source project and from >> what you say so is tac_plus. I would imagine patches would be >> welcomed by both projects which would allow the tac_plus daemon to >> utilize IPA as it's back end. We would be happy to answer any >> questions for the person(s) who wanted to undertake this and >> contribute their work. >> > From what I can see it looks like the missing piece would be the > ability to look up tac_plus user->group assignments from the > FreeIPA/389 LDAP server. It looks like tac_plus has ""integrated"" the > authentication with LDAP via PAM, but not the authorization. When > building an authentication solution for network devices with FreeIPA, > providing authentication via TACACS+ would be secondary, since you > could have your Cisco device directly authenticate the user against > FreeIPA using Kerberos. TACACS+ primary benefit is in the granular > control of Authorization to network device services. If you can get > tac_plus to reference an LDAP server for group membership, then you > might have a reasonable solution. You would still need to assign the > group's network permissions in the tac_plus configuration file, but > that would be done once. Once the group access was defined, you could > assign LDAP users to groups that match what's in the tac_plus config > file. > > This really requires the tac_plus team to code direct LDAP integration > into their application similar to the way Freeradius can rely on an > LDAP server as a back-end. The local PAM stack was not really intended > to be a service that can be farmed out for other systems to use. It > was meant as a way to provide access to local services running on that > system. To use PAM for group membership (I.E. through the pam_listfile > ACL) would require a separate tac_plus daemon and PAM configuration > for each network device. I generally agree with John and James. Just want to add a bit about the roadmap and plans. With the open source whatever makes sense and is needed gets implemented. The TACACS support is not on the roadmap now but it can be if there is a real need in the community. There is no need to make it fully integrated day one. It can be a gradual process. The first step would be to set up TACACS server and use IPA for authentication via PAM proxy on the TACACS server or via PAM auth on the device itself. The full integration would be for the TACACS server to read all its identity and configuration information from LDAP . It will take time and a lot of effort for this to happen. There are gradual interim solutions in between. If someone wants to drive it with the TACACS community we are all open to assist and guide on the IPA/SSSD side. Regarding the groups mentioned above. I am not familiar with the TACACS code but I would assume that it uses the libc functions to get user and group entries. If this is the case than nsswitch can be configured to use identities provided by IPA via nss_ldap or better via SSSD. So the identities and authentication would come from the same identity server. The TACACS server will still hold the policies but those can be moved to LDAP back end gradually with collaboration with the TACACS community if there is more need than the basic integration described here can provide. Thanks Dmitri > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@red
Re: [Freeipa-users] Feature request: TACACS+ integration
On 08/25/2010 11:22 AM, James Roman wrote: The more practical solution which may be available to you would be to avail yourself of the PAM integration in the tac_plus project (but to be honest I don't see how that would give you any of the sophisticated features you cite as being a prime motivator for utilization of TACACS). FreeIPA is an open source project and from what you say so is tac_plus. I would imagine patches would be welcomed by both projects which would allow the tac_plus daemon to utilize IPA as it's back end. We would be happy to answer any questions for the person(s) who wanted to undertake this and contribute their work. From what I can see it looks like the missing piece would be the ability to look up tac_plus user->group assignments from the FreeIPA/389 LDAP server. It looks like tac_plus has ""integrated"" the authentication with LDAP via PAM, but not the authorization. When building an authentication solution for network devices with FreeIPA, providing authentication via TACACS+ would be secondary, since you could have your Cisco device directly authenticate the user against FreeIPA using Kerberos. TACACS+ primary benefit is in the granular control of Authorization to network device services. If you can get tac_plus to reference an LDAP server for group membership, then you might have a reasonable solution. You would still need to assign the group's network permissions in the tac_plus configuration file, but that would be done once. Once the group access was defined, you could assign LDAP users to groups that match what's in the tac_plus config file. This really requires the tac_plus team to code direct LDAP integration into their application similar to the way Freeradius can rely on an LDAP server as a back-end. The local PAM stack was not really intended to be a service that can be farmed out for other systems to use. It was meant as a way to provide access to local services running on that system. To use PAM for group membership (I.E. through the pam_listfile ACL) would require a separate tac_plus daemon and PAM configuration for each network device. Adding ldap queries to tac_plus would be the most general solution in which case this would have little direct relevance to IPA. However the schema we use, ACL's and internal "business logic" applied on top of LDAP queries might not map easily to a generic LDAP interface in tac_plus. I really don't know. All of this is to say there is another way to use IPA as a backend service besides connecting to our LDAP server. We do support an XML-RPC interface that is fully authenticated and encrypted. So another options would be for tac_plus to make RPC calls. Just a thought. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
From both a network and a security point of view, TACACS+ is considered preferable to RADIUS; among other benefits, it enciphers the entire conversation, rather than just portions of it, and can provide more fine-grain authorization than RADIUS. Most Cisco shops I've encountered consider RADIUS to be an unacceptable solution for AAA. Cisco considers use of TACACS+ a best practice for AAA. What I am looking for is a device on the network which provides AAA facilities to network infrastructure devices, and which allows provisioning of network infrastructure credentials through the same interface and at the same time as systems credentials, and which keeps those credentials synchronized. O.K. fair enough. However TACACS is not on our roadmap. If you can demonstrate strong need by enterprise customers for TACACS it would be taken into consideration for a future version of the product. The more practical solution which may be available to you would be to avail yourself of the PAM integration in the tac_plus project (but to be honest I don't see how that would give you any of the sophisticated features you cite as being a prime motivator for utilization of TACACS). FreeIPA is an open source project and from what you say so is tac_plus. I would imagine patches would be welcomed by both projects which would allow the tac_plus daemon to utilize IPA as it's back end. We would be happy to answer any questions for the person(s) who wanted to undertake this and contribute their work. From what I can see it looks like the missing piece would be the ability to look up tac_plus user->group assignments from the FreeIPA/389 LDAP server. It looks like tac_plus has ""integrated"" the authentication with LDAP via PAM, but not the authorization. When building an authentication solution for network devices with FreeIPA, providing authentication via TACACS+ would be secondary, since you could have your Cisco device directly authenticate the user against FreeIPA using Kerberos. TACACS+ primary benefit is in the granular control of Authorization to network device services. If you can get tac_plus to reference an LDAP server for group membership, then you might have a reasonable solution. You would still need to assign the group's network permissions in the tac_plus configuration file, but that would be done once. Once the group access was defined, you could assign LDAP users to groups that match what's in the tac_plus config file. This really requires the tac_plus team to code direct LDAP integration into their application similar to the way Freeradius can rely on an LDAP server as a back-end. The local PAM stack was not really intended to be a service that can be farmed out for other systems to use. It was meant as a way to provide access to local services running on that system. To use PAM for group membership (I.E. through the pam_listfile ACL) would require a separate tac_plus daemon and PAM configuration for each network device. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
On 08/25/2010 08:21 AM, david klein wrote: On Wed, Aug 25, 2010 at 6:50 AM, John Dennis wrote: On 08/24/2010 11:22 PM, david klein wrote: Sorry to those who have already seen this; I posted to the wrong mailing list (the -interest mailing list instead of the -users list). As an NMS engineer, I have a use for integrated TACACS+ with a unified identity solution, so that the same account name and password can grant access for managing network infrastructure devices as well as UNIX and Linux servers, and so that network rights can be assigned and delegated through the same GUI as systems rights. There is an open source TACACS+ service called "tac_plus", which used to be maintained by Cisco, and which is now maintained by Shrubbery Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that under Shrubbery's guidance and development, the tac_plus daemon can use LDAP by way of PAM to handle authentication, according to http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only authentication appears to have been externalized, but it does prove the concept. How does Redhat currently measure the degree of interest in possible features for inclusion in the FreeIPA/EnterpriseIPA product, and would it be worthwhile to gather statements from other systems administrators to help demonstrate the desirability and usefulness of this feature request? This would be a very helpful capability, as it would remove dependence on ACS, which is expensive and complex (and complicated) TACACS+ server. This is the first request I've seen for TACAS support. Since IPA is a unified identity solution at it's core it's not clear to me at the moment what advantage there would be to TACAS other than as emulating a TACAS server for legacy and/or 3rd party products which depend on the TACAS protocol. If one wants to set up a TACAS daemon there is a reasonable chance it could validate against IPA (more investigation would be needed) and this would give you something which provide TACAS protocol but be backed by IPA and it's management tools. We do have plans on our roadmap to support RADIUS which is often used as an alternative to TACAS. But perhaps I haven't fully understood your request. So let me rephrase it and see if I have it correct. You want something on your network which speaks the TACAS+ protocol but whose identity management is backed by our IPA server. Is that correct? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From both a network and a security point of view, TACACS+ is considered preferable to RADIUS; among other benefits, it enciphers the entire conversation, rather than just portions of it, and can provide more fine-grain authorization than RADIUS. Most Cisco shops I've encountered consider RADIUS to be an unacceptable solution for AAA. Cisco considers use of TACACS+ a best practice for AAA. What I am looking for is a device on the network which provides AAA facilities to network infrastructure devices, and which allows provisioning of network infrastructure credentials through the same interface and at the same time as systems credentials, and which keeps those credentials synchronized. O.K. fair enough. However TACACS is not on our roadmap. If you can demonstrate strong need by enterprise customers for TACACS it would be taken into consideration for a future version of the product. The more practical solution which may be available to you would be to avail yourself of the PAM integration in the tac_plus project (but to be honest I don't see how that would give you any of the sophisticated features you cite as being a prime motivator for utilization of TACACS). FreeIPA is an open source project and from what you say so is tac_plus. I would imagine patches would be welcomed by both projects which would allow the tac_plus daemon to utilize IPA as it's back end. We would be happy to answer any questions for the person(s) who wanted to undertake this and contribute their work. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
On Wed, Aug 25, 2010 at 6:50 AM, John Dennis wrote: > On 08/24/2010 11:22 PM, david klein wrote: >> >> Sorry to those who have already seen this; I posted to the wrong >> mailing list (the -interest mailing list instead of the -users list). >> >> As an NMS engineer, I have a use for integrated TACACS+ with a unified >> identity solution, so that the same account name and password can >> grant access for managing network infrastructure devices as well as >> UNIX and Linux servers, and so that network rights can be assigned and >> delegated through the same GUI as systems rights. >> >> There is an open source TACACS+ service called "tac_plus", which used >> to be maintained by Cisco, and which is now maintained by Shrubbery >> Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that >> under Shrubbery's guidance and development, the tac_plus daemon can >> use LDAP by way of PAM to handle authentication, according to >> http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only >> authentication appears to have been externalized, but it does prove >> the concept. >> >> How does Redhat currently measure the degree of interest in possible >> features for inclusion in the FreeIPA/EnterpriseIPA product, and would >> it be worthwhile to gather statements from other systems >> administrators to help demonstrate the desirability and usefulness of >> this feature request? This would be a very helpful capability, as it >> would remove dependence on ACS, which is expensive and complex (and >> complicated) TACACS+ server. > > This is the first request I've seen for TACAS support. Since IPA is a > unified identity solution at it's core it's not clear to me at the moment > what advantage there would be to TACAS other than as emulating a TACAS > server for legacy and/or 3rd party products which depend on the TACAS > protocol. If one wants to set up a TACAS daemon there is a reasonable chance > it could validate against IPA (more investigation would be needed) and this > would give you something which provide TACAS protocol but be backed by IPA > and it's management tools. > > We do have plans on our roadmap to support RADIUS which is often used as an > alternative to TACAS. > > But perhaps I haven't fully understood your request. So let me rephrase it > and see if I have it correct. You want something on your network which > speaks the TACAS+ protocol but whose identity management is backed by our > IPA server. Is that correct? > > -- > John Dennis > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > >From both a network and a security point of view, TACACS+ is considered preferable to RADIUS; among other benefits, it enciphers the entire conversation, rather than just portions of it, and can provide more fine-grain authorization than RADIUS. Most Cisco shops I've encountered consider RADIUS to be an unacceptable solution for AAA. Cisco considers use of TACACS+ a best practice for AAA. What I am looking for is a device on the network which provides AAA facilities to network infrastructure devices, and which allows provisioning of network infrastructure credentials through the same interface and at the same time as systems credentials, and which keeps those credentials synchronized. -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Feature request: TACACS+ integration
On 08/24/2010 11:22 PM, david klein wrote: Sorry to those who have already seen this; I posted to the wrong mailing list (the -interest mailing list instead of the -users list). As an NMS engineer, I have a use for integrated TACACS+ with a unified identity solution, so that the same account name and password can grant access for managing network infrastructure devices as well as UNIX and Linux servers, and so that network rights can be assigned and delegated through the same GUI as systems rights. There is an open source TACACS+ service called "tac_plus", which used to be maintained by Cisco, and which is now maintained by Shrubbery Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that under Shrubbery's guidance and development, the tac_plus daemon can use LDAP by way of PAM to handle authentication, according to http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only authentication appears to have been externalized, but it does prove the concept. How does Redhat currently measure the degree of interest in possible features for inclusion in the FreeIPA/EnterpriseIPA product, and would it be worthwhile to gather statements from other systems administrators to help demonstrate the desirability and usefulness of this feature request? This would be a very helpful capability, as it would remove dependence on ACS, which is expensive and complex (and complicated) TACACS+ server. This is the first request I've seen for TACAS support. Since IPA is a unified identity solution at it's core it's not clear to me at the moment what advantage there would be to TACAS other than as emulating a TACAS server for legacy and/or 3rd party products which depend on the TACAS protocol. If one wants to set up a TACAS daemon there is a reasonable chance it could validate against IPA (more investigation would be needed) and this would give you something which provide TACAS protocol but be backed by IPA and it's management tools. We do have plans on our roadmap to support RADIUS which is often used as an alternative to TACAS. But perhaps I haven't fully understood your request. So let me rephrase it and see if I have it correct. You want something on your network which speaks the TACAS+ protocol but whose identity management is backed by our IPA server. Is that correct? -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Feature request: TACACS+ integration
Sorry to those who have already seen this; I posted to the wrong mailing list (the -interest mailing list instead of the -users list). As an NMS engineer, I have a use for integrated TACACS+ with a unified identity solution, so that the same account name and password can grant access for managing network infrastructure devices as well as UNIX and Linux servers, and so that network rights can be assigned and delegated through the same GUI as systems rights. There is an open source TACACS+ service called "tac_plus", which used to be maintained by Cisco, and which is now maintained by Shrubbery Networks, Inc (http://www.shrubbery.net/tac_plus/). It appears that under Shrubbery's guidance and development, the tac_plus daemon can use LDAP by way of PAM to handle authentication, according to http://www.shrubbery.net/tac_plus/PAM_guide.txt. At this point, only authentication appears to have been externalized, but it does prove the concept. How does Redhat currently measure the degree of interest in possible features for inclusion in the FreeIPA/EnterpriseIPA product, and would it be worthwhile to gather statements from other systems administrators to help demonstrate the desirability and usefulness of this feature request? This would be a very helpful capability, as it would remove dependence on ACS, which is expensive and complex (and complicated) TACACS+ server. Thank you, -DTK -- david t. klein Cisco Certified Network Associate (CSCO11281885) Linux Professional Institute Certification (LPI000165615) Redhat Certified Engineer (805009745938860) Quis custodiet ipsos custodes? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
