Michael Mercier wrote:
On 2012-08-22, at 4:12 PM, Rob Crittenden wrote:

Michael Mercier wrote:
Hello,

In Aug 2010, someone posted a message to this list about integrating
tacacs+ with freeipa
https://www.redhat.com/archives/freeipa-users/2010-August/msg00058.html

At the time, it was mentioned that this was not on the roadmap, has this
changed?

No, still not on the roadmap.


If RedHat has no plans to do this, where can I find the freeipa
documentation that would allow me to do a proof-of-concept?  I would use
the freely available tac_plus (http://www.shrubbery.net/tac_plus/) as a
staring point.

http://freeipa.org/page/Contribute (in Developer Documentation and Developement 
Process) and
http://abbra.fedorapeople.org/freeipa-extensibility.html


Some of the specific things I am looking for:
1.  How should passwords be verified?  sssd, pam, ldap lookup, krb?
2.  How the ldap schema should be designed for best integration?

I'd start by seeing if there is already one defined as a real or quasi standard.

3.  The proper way to query the ldap server (standard ldap calls or is
there some specific freeipa api)

Standard LDAP calls.

4.  I am sure I am not asking something!!

I tried asking some similar questions on freeipa-devel but didn't
receive a response.

rob

Hello,

I have started playing with having the tac_plus daemon use Freeipa and have 
some questions regarding HBAC.

I have done the following:

1.  Created a DNS entry for my device:  pix.beta.local <-> 192.168.0.1
2.  Disabled the 'allow_all' HBAC rule
3.  Created an HBAC rule tacacs with the following:
   a) who: user group: ciscoadmin - user mike is part of ciscoadmin
   b) Accessing: hosts: pix.beta.local
   c) via service: tac_plus
   d) from: any host

I can successfully login (auth) to a Cisco ASA via the tac_plus daemon using 
PAM.  I have added some code to also attempt to do PAM accounting for the 
device and can't get this to work.

Aug 28 16:13:34 ipaserver tac_plus[2217]: pam_sss(tac_plus:auth): 
authentication success; logname=root uid=0 euid=0 tty= ruser= rhost=192.168.0.1 
user=mike
Aug 28 16:13:34 ipaserver tac_plus[2217]: pam_sss(tac_plus:account): Access 
denied for user mike: 6 (Permission denied)

If I add the host (ipaserver.beta.local) the daemon is running on to the 
'Accessing' list or enable the 'allow_all' rule, I am able to login.

I see the following in my audit.log
type=USER_AUTH msg=audit(1346184814.834:168): user pid=2217 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication 
acct="mike" exe="/home/tacacs/tacacs+-F4.0.4.26/.libs/lt-tac_plus" 
hostname=192.168.0.1 addr=192.168.0.1 terminal=pts/0 res=success'
type=USER_ACCT msg=audit(1346184814.845:169): user pid=2217 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting 
acct="mike" exe="/home/tacacs/tacacs+-F4.0.4.26/.libs/lt-tac_plus" 
hostname=192.168.0.1 addr=192.168.0.1 terminal=pts/0 res=failed'

It seems that the machine the daemon is running on is being used for the HBAC 
rule (at least that is what is looks like from the dirsrv access log)
[28/Aug/2012:16:13:33 -0400] conn=29 op=45 SRCH base="cn=hbac,dc=beta,dc=local" scope=2 
filter="(&(objectClass=ipaHBACRule)(ipaEnabledFlag=TRUE)(|(hostCategory=all)(memberHost=fqdn=ipaserver.beta.local,cn=computers,cn=accounts,dc=beta,dc=local)))"
 attrs="objectClass cn ipaUniqueID ipaEnabledFlag accessRuleType memberUser userCategory memberService 
serviceCategory sourceHost sourceHostCategory externalHost memberHost hostCategory"

Is it possible to get the 'hostname' (pix.beta.local/192.168.0.1) passed 
through to HBAC?
It looks like the 'msg' portion of the audit data is coming from PAM (Is this 
correct)?
Should I be posting this to the devel list instead?


An educated guess would be that the tac_plus daemon would need to be modified to send the requesting server hostname to PAM.

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to