[Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.

[Орхан Касумов]

Alright then, thanks for info!
Tomorrow is the deadline for my researches on FreeIPA.
Then I have to start deploying a centralized management solution in our production environment.
Please help me to make a final decision on which version of FreeIPA to choose - 3.3 or 4.1?
I'd like to have all the benefits of the latest version, but all our production servers are FreeBSD.
With all information sources at my disposal right now I tend to choose FreeIPA 3.3.
The cause is that otherwise I can't use host groups with sudo commands -
the cron script proposed at FreeBSD forums works with old way of storing host group information in the LDAP directory of FreeIPA.
Is there any workaround for this? (P.S. Here's what I'm talking about:
>" The tricky part was getting  sudo  to work with host groups. FreeIPA keeps host groups in netgroups, and FreeBSD's support for netgroups is limited. One solution would have been to enable NIS services on the FreeIPA server so that we could use proper netgroups on FreeBSD clients. We didn't like that solution, so instead we wrote a script that pulls all netgroup data from FreeIPA and stores it in  /etc/netgroup . We run the script every hour via  cron . "
>
>The script looks for host groups in 'cn=hostgroups,cn=accounts,dc=<domain>', and that works with FreeIPA 3.3. But in FreeIPA v4 host groups get in 'cn=ng,cn=compat,dc=<domain>'. So the script needs modification. But I don't know how to modify the script, simply changing the string passed to the ldapsearch command doesn't work.)


Thu, 23 Oct 2014 16:41:55 +0300 от Alexander Bokovoy <abokovoy at redhat.com>:
>On Thu, 23 Oct 2014, Orkhan Gasimov wrote:
>>And another interesting behaviour.
>>
>>Say a user "netuser" is a member of a user group "netstaff",
>>and a host "bsd.example.com" is a member of a host group "nethosts".
>>We then create an HBAC rule "netstaff_to_nethosts":
>>
>>Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- 
>>Via Service: Specified Services and Groups -> sshd
>Here you are allowing only sshd service for use.
>
>>
>>And we create a SUDO rule "test":
>>
>>Who: Specified Users and Groups -> netuser -- Access this host: 
>>bsd.example.com -- Run Commands: Any Command
>>
>>Expected result is this: user "netuser" should be able to SSH to host 
>>"bsd.example.com" and successfully issue the command "sudo shutdown -r 
>>now".
>>
>>What happens instead: user "netuser" is able to SSH to host 
>>"bsd.example.com", but issuing the command "sudo shutdown -r now" 
>>produces this output (password is entered correctly):
>>
>>$ shutdown -r now
>>Password:
>>Ying Tong Iddle I Po
>>Password:
>>Do you think like you type?
>>Password:
>>Have you considered trying to match wits with a rutabaga?
>>
>>This is funny, and you can continue trying sudo and getting funny 
>>outputs; but the only way for the command to work properly is to 
>>change the HBAC rule:
>>
>>Who: User Groups -> netstaff -- Accessing: Host Groups -> nethosts -- 
>>Via Service: Specified Services and Groups -> ANY SERVICE
>>
>>Is this the correct behavior? I don't remember anything like this in 
>>FreeIPA 3.3.
>Yes. The behaviour did not change since may be FreeIPA 2.0.
>
>sudo does authenticate and authorize user first via PAM stack and then applies own
>ruleset. So HBAC rules get applied here and since you don't have
>allow_all rule that would allow any user to access any service on any
>host, you get denial.
>
>Instead of using only sshd service in HBAC rule, make a service group
>and add both sshd and sudo there.
>
>Alternatively you can add multiple HBAC rules, one for sshd, one for
>sudo.
>
>
>-- 
>/ Alexander Bokovoy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20141023/26f0d5c6/attachment.htm>