Re: [Freeipa-users] HBAC not working, freeipa 4.4, sssd 1.15.1

[Jakub Hrozek]

On Fri, Mar 17, 2017 at 08:35:42AM +1100, Lachlan Musicman wrote:
> Which logs do you want from the server?

NSS and domain

-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

[Lachlan Musicman]

Which logs do you want from the server?

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 16 March 2017 at 20:09, Jakub Hrozek  wrote:

> On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote:
> > Yes. What I do would you like? Current debug levels are at 8
>
> Logs and id output from the server and the client at the same time..
>
-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

[Jakub Hrozek]

On Thu, Mar 16, 2017 at 07:56:58PM +1100, Lachlan Musicman wrote:
> Yes. What I do would you like? Current debug levels are at 8

Logs and id output from the server and the client at the same time..

-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

[Lachlan Musicman]

Yes. What I do would you like? Current debug levels are at 8

L.

On 16 Mar. 2017 7:06 pm, "Jakub Hrozek"  wrote:

> On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote:
> > I'm experiencing issues with HBAC and I think it's a bug in sssd. Not
> sure
> > if better to report to here or sssd mailing list. Also sssd in pagure is
> > bare and I didn't want to sully the blank slate.  (
> > https://pagure.io/sssd/issues )
> >
> > The details:
> >
> > env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR
> >
> > On the IPA server:
> >
> > - "ipa hbactest ..." returns TRUE, so everything seems set up correctly.
> >
> >
> > When I try to login to the test client, I get denied.
> >
> > On the test client:
> >
> >  - hbac_eval_user_element is returning a wrong value. This is seen in
> > sssd_domain.log, it's returning 25. My test user is in 37 groups. This is
> > seen on the IPA server via id username. On the test client id username
> > returns 36 groups, the one missing is an IPA (not AD) group that was made
> > for HBAC rules. I have sanitized logs available.
> >
> >  -  taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb
> > '(objectclass=user)' and finding the record in question shows the same 36
> > groups available. The missing group shouldn't affect ability to login via
> > HBAC
> >
> >  - getent group (groupname) works as expected. Also worth noting that the
> > group missing from id username shows that user in getent.
> >
> > For reference, on the client the sssd service was stopped, the cache
> > deleted, and the service started again the night before after which the
> > server wasn't accessed by anyone. I find that this is necessary for the
> > cache to populate.
> >
> > Should I put in a bug report against SSSD or FreeIPA?
> >
> > While HBAC is in FreeIPA, I think that this is an issue in SSSD
> > (specifically ?
>
> Yes, SSSD.
>
> I remember you had some intermittent issues in the past, is this one
> reproducable?
>
> --
> 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
>
-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

[Jakub Hrozek]

On Thu, Mar 16, 2017 at 11:36:57AM +1100, Lachlan Musicman wrote:
> I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure
> if better to report to here or sssd mailing list. Also sssd in pagure is
> bare and I didn't want to sully the blank slate.  (
> https://pagure.io/sssd/issues )
> 
> The details:
> 
> env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR
> 
> On the IPA server:
> 
> - "ipa hbactest ..." returns TRUE, so everything seems set up correctly.
> 
> 
> When I try to login to the test client, I get denied.
> 
> On the test client:
> 
>  - hbac_eval_user_element is returning a wrong value. This is seen in
> sssd_domain.log, it's returning 25. My test user is in 37 groups. This is
> seen on the IPA server via id username. On the test client id username
> returns 36 groups, the one missing is an IPA (not AD) group that was made
> for HBAC rules. I have sanitized logs available.
> 
>  -  taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb
> '(objectclass=user)' and finding the record in question shows the same 36
> groups available. The missing group shouldn't affect ability to login via
> HBAC
> 
>  - getent group (groupname) works as expected. Also worth noting that the
> group missing from id username shows that user in getent.
> 
> For reference, on the client the sssd service was stopped, the cache
> deleted, and the service started again the night before after which the
> server wasn't accessed by anyone. I find that this is necessary for the
> cache to populate.
> 
> Should I put in a bug report against SSSD or FreeIPA?
> 
> While HBAC is in FreeIPA, I think that this is an issue in SSSD
> (specifically ?

Yes, SSSD.

I remember you had some intermittent issues in the past, is this one
reproducable?

-- 
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] HBAC not working, freeipa 4.4, sssd 1.15.1

[Lachlan Musicman]

I'm experiencing issues with HBAC and I think it's a bug in sssd. Not sure
if better to report to here or sssd mailing list. Also sssd in pagure is
bare and I didn't want to sully the blank slate.  (
https://pagure.io/sssd/issues )

The details:

env: CentOS 7.3, FreeIPA 4.4, sssd 1.15.1 from COPR

On the IPA server:

- "ipa hbactest ..." returns TRUE, so everything seems set up correctly.


When I try to login to the test client, I get denied.

On the test client:

 - hbac_eval_user_element is returning a wrong value. This is seen in
sssd_domain.log, it's returning 25. My test user is in 37 groups. This is
seen on the IPA server via id username. On the test client id username
returns 36 groups, the one missing is an IPA (not AD) group that was made
for HBAC rules. I have sanitized logs available.

 -  taking ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb
'(objectclass=user)' and finding the record in question shows the same 36
groups available. The missing group shouldn't affect ability to login via
HBAC

 - getent group (groupname) works as expected. Also worth noting that the
group missing from id username shows that user in getent.

For reference, on the client the sssd service was stopped, the cache
deleted, and the service started again the night before after which the
server wasn't accessed by anyone. I find that this is necessary for the
cache to populate.

Should I put in a bug report against SSSD or FreeIPA?

While HBAC is in FreeIPA, I think that this is an issue in SSSD
(specifically ?


cheers
L.




--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] HBAC trust groups inconsistent

[Mike Berkelaar]

Hello,

I have been testing Freeipa since 4.2 and am very impressed overall. A pending 
issue I have not been able to resolve is getting HBAC to work consistently. I’m 
limited to an AD-trust scenario where AD groups are mapped to Posix groups. 
While ‘id user@domain’ will return all groups for new queries, or after a reset 
of the cache and a restart of SSSD, this does not *always* seem to be the case 
with kerberized HTTP. (http://www.freeipa.org/page/Web_App_Authentication)

With the HBAC rule allowing access from a particular Posix mapped group to a 
custom service (‘HTTP’) I typically see it sometimes working, and then randomly 
failing after some delay ( minutes – hours), hinting at a cache miss of some 
sort.

Performing an HTTP GET to the kerberized webserver may at first fail. After a 
short delay it may sometimes start working out of the blue. In some cases 
disabling and enabling HBAC rules or performing ‘id user@domain’ helps with 
sorting the issue. As you can see from the logging the first time SSSD gathers 
38 groups, failing to get the Posix mapped group, but a few minutes later 
getting 39 groups, including the ‘sambatesters’ mapped group that the HBAC rule 
applies to.

Failing:
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[hbac_eval_user_element] (0x1000): [38] groups for [user@domain.local]
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[hbac_eval_user_element] (0x2000): Skipping non-group memberOf 
[CN=SG_ROLE_PROXY_PROD_Change,OU=Roles,OU=Groups,DC=domain,DC=local]
... * Skipping all underscore_seperated_group CNs *
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=* ICT 
Infrastructure Unix,OU=Distribution,OU=Groups,DC=domain,DC=local]

(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x21a9f4
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x21e99e0
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): 
Running timer event 0x21a9f40 "ltdb_callback"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): 
Destroying timer event 0x21e99e0 "ltdb_timeout"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Ending 
timer event 0x21a9f40 "ltdb_callback"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x21c90c0
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x21b6e00
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): 
Running timer event 0x21c90c0 "ltdb_callback"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): 
Destroying timer event 0x21b6e00 "ltdb_timeout"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Ending 
timer event 0x21c90c0 "ltdb_callback"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x21eb880
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x21b6e00
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): 
Running timer event 0x21eb880 "ltdb_callback"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): 
Destroying timer event 0x21b6e00 "ltdb_timeout"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [ldb] (0x4000): Ending 
timer event 0x21eb880 "ltdb_callback"
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [sdap_id_op_destroy] 
(0x4000): releasing operation connection
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (0, 6, ) [Success]
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[be_pam_handler_callback] (0x0100): Sending result [6][domain.local]
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] 
[be_pam_handler_callback] (0x0100): Sent result [6][domain.local]
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [sdap_process_result] 
(0x2000): Trace: sh[0x21a6b10], connected[1], ops[(nil)], ldap[0x21ab2b0]
(Tue Jan 24 19:05:42 2017) [sssd[be[unix.domain.local]]] [sdap_process_result] 
(0x2000): Trace: ldap_result found nothing!


Succeeding:
(Tue Jan 24 19:06:58 2017) [sssd[be[unix.domain.local]]] 
[hbac_eval_user_element] (0x1000): [39] groups for [user@domain.local]
(Tue Jan 24 19:06:58 2017) [sssd[be[unix.domain.local]]] 
[hbac_eval_user_element] (0x2000): Skipping non-group memberOf 
[CN=SG_ROLE_PROXY_PROD_Change,OU=Roles,OU=Groups,DC=domain,DC=local]
...
(Tue Jan 24 19:06:58 2017) [sssd[be[unix.domain.local]]] 
[hbac_eval_user_element] (0x2000): Skipping non-group memberOf [CN=AFD-ICT-DM 
Change,OU=_SOMEOU,OU=Groups,DC=domain,DC=l

Re: [Freeipa-users] HBAC Troubleshooting (IPA 4.2)

[Jake]

Details: 
ipa-client-install --version 
4.2.0 

sssd --version 
1.13.0 

krb5-config --version 
Kerberos 5 release 1.13.2 

cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 

I hope this helps, also can I disable the allow-all rule per-host? 

Thanks, 
Jake 


From: "Lachlan Musicman"  
Cc: "freeipa-users"  
Sent: Tuesday, November 1, 2016 7:04:45 PM 
Subject: Re: [Freeipa-users] HBAC Troubleshooting (IPA 4.2) 

Jake, 

I've seen this behaviour and am still struggling to find a solution. 

The version of underlying OS and sssd are useful to know fwiw. 

To trouble shoot HBAC: 

- in *target machine* sssd.conf, add debug_level=7 to each stanza (can go as 
high as 9, but I believe 7 will be sufficient) 
- restart sssd 
- clear logs in /var/log/sssd/ either by deleting or by logrotate 
- make an attempt to login/perform allowed action that gets denied 
- read logs to see what happened 
- I like to run `ipa hbactest --user= --host= --service` on the IPA node to 
confirm that the HBAC rules are correct 
- I sometimes also install ipa-tools on the target host and confirm that the 
above command gives same and correct answer 
- note that successful results from this command may not translate to 
successful application of HBAC on the target host in reality. 



cheers 
L. 


-- 
The most dangerous phrase in the language is, "We've always done it this way." 

- Grace Hopper 

On 2 November 2016 at 09:41, Jake < [ mailto:free...@jacobdevans.com | 
free...@jacobdevans.com ] > wrote: 



Hey All, 
I'm having some issues tracing HBAC policies, it seems whenever I disable the 
allow_all policy, I'm no longer able to access services I have allowed in my 
more-specific hbac policy. 

What are the troubleshooting steps (logs) I can run on the client to see what 
is being denied and by what policy, Is this all done with sssd? 

Thank You, 
-Jake 


-- 
Manage your subscription for the Freeipa-users mailing list: 
[ https://www.redhat.com/mailman/listinfo/freeipa-users | 
https://www.redhat.com/mailman/listinfo/freeipa-users ] 
Go to [ http://freeipa.org/ | http://freeipa.org ] for more info on the project 





-- 
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 

-- 
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] HBAC Troubleshooting (IPA 4.2)

[Lachlan Musicman]

Jake,

I've seen this behaviour and am still struggling to find a solution.

The version of underlying OS and sssd are useful to know fwiw.

To trouble shoot HBAC:

 - in *target machine* sssd.conf, add debug_level=7 to each stanza (can go
as high as 9, but I believe 7 will be sufficient)
 - restart sssd
 - clear logs in /var/log/sssd/ either by deleting or by logrotate
 - make an attempt to login/perform allowed action that gets denied
 - read logs to see what happened
 - I like to run `ipa hbactest --user= --host= --service` on the IPA node
to confirm that the HBAC rules are correct
 - I sometimes also install ipa-tools on the target host and confirm that
the above command gives same and correct answer
 - note that successful results from this command may not translate to
successful application of HBAC on the target host in reality.



cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 2 November 2016 at 09:41, Jake  wrote:

> Hey All,
> I'm having some issues tracing HBAC policies, it seems whenever I disable
> the allow_all policy, I'm no longer able to access services I have allowed
> in my more-specific hbac policy.
>
> What are the troubleshooting steps (logs) I can run on the client to see
> what is being denied and by what policy, Is this all done with sssd?
>
> Thank You,
> -Jake
>
>
> --
> 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
>
-- 
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] HBAC Troubleshooting (IPA 4.2)

[Jake]

Hey All, 
I'm having some issues tracing HBAC policies, it seems whenever I disable the 
allow_all policy, I'm no longer able to access services I have allowed in my 
more-specific hbac policy. 

What are the troubleshooting steps (logs) I can run on the client to see what 
is being denied and by what policy, Is this all done with sssd? 

Thank You, 
-Jake 

-- 
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] HBAC rules stop working

[Jakub Hrozek]

On Thu, Sep 29, 2016 at 07:51:14PM -0600, Orion Poplawski wrote:
> server:
> ipa-server-4.2.0-15.sl7_2.19.x86_64
> sssd-1.13.0-40.el7_2.12.x86_64
> 
> client:
> sssd-1.14.1-3.el7.centos.x86_64
> 
> AD trust - users are in AD.  HBAC rule in place for client to allow a user
> to login/ssh/su/etc.
> 
> This seems to have happened a couple times now, and again today after
> rebooting the IPA server.  sssd was denying the user to ssh into the client
> by pam rules.  Logged on to the IPA server and disabled and then re-enabled
> the HBAC rule for the client and then was able to log back in again.  Has
> anyone else seen this before?
> 
> client sssd_pam just went from:
> 
> (Thu Sep 29 19:30:40 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [6]: Permission denied.
> 
> to
> 
> (Thu Sep 29 19:37:04 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [0]: Success.
> 
> so I assume I'll need to collect debug logs from sssd on the server next
> time.

Yes..please try to collect logs from a machine that exhibits the bug. I
suspect this is not related to HBAC per se, but rather to external group
memberships, so it would also be nice to check if the groups are
resolved on the faulty machine. And if they wouldn't be, please also
check if they are resolved on the server itself (and collect logs
there..)

-- 
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] HBAC rules stop working

[Orion Poplawski]

server:
ipa-server-4.2.0-15.sl7_2.19.x86_64
sssd-1.13.0-40.el7_2.12.x86_64

client:
sssd-1.14.1-3.el7.centos.x86_64

AD trust - users are in AD.  HBAC rule in place for client to allow a 
user to login/ssh/su/etc.


This seems to have happened a couple times now, and again today after 
rebooting the IPA server.  sssd was denying the user to ssh into the 
client by pam rules.  Logged on to the IPA server and disabled and then 
re-enabled the HBAC rule for the client and then was able to log back in 
again.  Has anyone else seen this before?


client sssd_pam just went from:

(Thu Sep 29 19:30:40 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply 
called with result [6]: Permission denied.


to

(Thu Sep 29 19:37:04 2016) [sssd[pam]] [pam_reply] (0x0200): pam_reply 
called with result [0]: Success.


so I assume I'll need to collect debug logs from sssd on the server next 
time.


--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane  or...@cora.nwra.com
Boulder, CO 80301  http://www.cora.nwra.com

--
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] HBAC doesn't work issues

[Lachlan Musicman]

(redface)

It seems to be working.

Thanks


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 September 2016 at 09:57, Lachlan Musicman  wrote:

> We have one "allow all" sudo rule (anyone, any host, any command).
>
> Matching Defaults entries for root on this host:
> requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
> DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
> PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
> LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
> LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
> LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
> secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
>
> User root may run the following commands on this host:
> (ALL) ALL
>
>
> My sssd.conf has:
>
> [domain/unixdev.etc]
> ...
> sudo_provider = ldap
> ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
> ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
> ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
> krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au
>
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> domains = unixdev.petermac.org.au
> debug_level = 6
>
> [sudo]
> debug_level = 6
>
> but only on the server - does that need to filter down to each client? The
> client side sssd.confs seem to be auto created when ipa-client-install is
> run, and are stripped down...
>
> cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 19 September 2016 at 18:21, Lukas Slebodnik 
> wrote:
>
>> On (19/09/16 16:43), Lachlan Musicman wrote:
>> >I must have made an error again:
>> >
>> >- ipa hbactest gives seemingly correct answer on both server and client
>> >- user can't actually use sudo on client?
>> >
>> >Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR
>> >
>> >>From the server:
>> >
>> >[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
>> >--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo
>> >
>> >Access granted: True
>> >
>> >  Matched rules: Cluster Admin Users (sudo)
>> >  Not matched rules: Cluster Users
>> >[root@vmdv-linuxidm1 ~]#
>> >
>> >
>> >>From the host in question:
>> >
>> >[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
>> >--host `hostname` --service sudo
>> >
>> >Access granted: True
>> >
>> >  Matched rules: Cluster Admin Users (sudo)
>> >  Not matched rules: Cluster Users
>> >[root@vmts-linuxclient1 ~]#
>> >
>> >
>> >[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
>> >[sudo] password for lsimp...@petermac.org.au:
>> >lsimp...@petermac.org.au is not allowed to run sudo on
>> vmts-linuxclient1.
>> >This incident will be reported.
>> >
>> Did you configure sudo rules for such user?
>> What is an output of "sudo -l"
>>
>> LS
>>
>
>
-- 
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] HBAC doesn't work issues

[Lachlan Musicman]

We have one "allow all" sudo rule (anyone, any host, any command).

Matching Defaults entries for root on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1
PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User root may run the following commands on this host:
(ALL) ALL


My sssd.conf has:

[domain/unixdev.etc]
...
sudo_provider = ldap
ldap_uri = ldap://vmdv-linuxidm1.unixdev.petermac.org.au
ldap_sudo_search_base = or=sudoers,dc=unixdev,dc=petermac,dc=org,dc=au
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/vmdv-linuxidm1.unixdev.petermac.org.au
ldap_sasl_realm = UNIXDEV.PETERMAC.ORG.AU
krb5_server = vmdv-linuxidm1.unixdev.petermac.org.au

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = unixdev.petermac.org.au
debug_level = 6

[sudo]
debug_level = 6

but only on the server - does that need to filter down to each client? The
client side sssd.confs seem to be auto created when ipa-client-install is
run, and are stripped down...

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 19 September 2016 at 18:21, Lukas Slebodnik  wrote:

> On (19/09/16 16:43), Lachlan Musicman wrote:
> >I must have made an error again:
> >
> >- ipa hbactest gives seemingly correct answer on both server and client
> >- user can't actually use sudo on client?
> >
> >Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR
> >
> >>From the server:
> >
> >[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
> >--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo
> >
> >Access granted: True
> >
> >  Matched rules: Cluster Admin Users (sudo)
> >  Not matched rules: Cluster Users
> >[root@vmdv-linuxidm1 ~]#
> >
> >
> >>From the host in question:
> >
> >[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
> >--host `hostname` --service sudo
> >
> >Access granted: True
> >
> >  Matched rules: Cluster Admin Users (sudo)
> >  Not matched rules: Cluster Users
> >[root@vmts-linuxclient1 ~]#
> >
> >
> >[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
> >[sudo] password for lsimp...@petermac.org.au:
> >lsimp...@petermac.org.au is not allowed to run sudo on vmts-linuxclient1.
> >This incident will be reported.
> >
> Did you configure sudo rules for such user?
> What is an output of "sudo -l"
>
> LS
>
-- 
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] HBAC doesn't work issues

[Lukas Slebodnik]

On (19/09/16 16:43), Lachlan Musicman wrote:
>I must have made an error again:
>
>- ipa hbactest gives seemingly correct answer on both server and client
>- user can't actually use sudo on client?
>
>Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR
>
>>From the server:
>
>[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
>--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo
>
>Access granted: True
>
>  Matched rules: Cluster Admin Users (sudo)
>  Not matched rules: Cluster Users
>[root@vmdv-linuxidm1 ~]#
>
>
>>From the host in question:
>
>[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
>--host `hostname` --service sudo
>
>Access granted: True
>
>  Matched rules: Cluster Admin Users (sudo)
>  Not matched rules: Cluster Users
>[root@vmts-linuxclient1 ~]#
>
>
>[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
>[sudo] password for lsimp...@petermac.org.au:
>lsimp...@petermac.org.au is not allowed to run sudo on vmts-linuxclient1.
>This incident will be reported.
>
Did you configure sudo rules for such user?
What is an output of "sudo -l"

LS

-- 
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] HBAC doesn't work issues

[Lachlan Musicman]

I must have made an error again:

- ipa hbactest gives seemingly correct answer on both server and client
- user can't actually use sudo on client?

Centos 7, freeipa 4.2.o/2.156; sssd 1.14.1 from COPR

>From the server:

[root@vmdv-linuxidm1 ~]# ipa hbactest --user=lsimp...@petermac.org.au
--host=vmts-linuxclient1.unixdev.petermac.org.au --service=sudo

Access granted: True

  Matched rules: Cluster Admin Users (sudo)
  Not matched rules: Cluster Users
[root@vmdv-linuxidm1 ~]#


>From the host in question:

[root@vmts-linuxclient1 ~]# ipa hbactest --user lsimp...@petermac.org.au
--host `hostname` --service sudo

Access granted: True

  Matched rules: Cluster Admin Users (sudo)
  Not matched rules: Cluster Users
[root@vmts-linuxclient1 ~]#


[lsimp...@petermac.org.au@vmts-linuxclient1 ~]$ sudo reboot
[sudo] password for lsimp...@petermac.org.au:
lsimp...@petermac.org.au is not allowed to run sudo on vmts-linuxclient1.
This incident will be reported.


On the client, in the sssd_sudo.log I can see (debug_level=6) a number of
lines, most notably three that start "Searching sysdb with" and then follow
with all my ipa and AD groups - both groups that would give me HBAC sudo
are listed in those log entries.

What should I try next?

cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] HBAC and AD users

[Lachlan Musicman]

Sure - I've got tomorrow off, so it will be Friday morning.

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 20 July 2016 at 17:14, Jakub Hrozek  wrote:

> On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> > On 19 July 2016 at 16:40, Jakub Hrozek  wrote:
> >
> > > On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > > > I think the thing that frustrates the most is that id
> u...@domain.com is
> > > > returning correct data on both but they can't loginand I can't
> even
> > > > show that this is the case because now they can login. Difficult to
> > > > reproduce :/
> > >
> > > Debugging from HBAC should at least tell you why the rules didn't
> > > match...
> > >
> >
> >
> > Sorry, I should have been clear - the issue is exactly the same. HBAC
> > rejected the user because they weren't in the correct groups, but sssd
> > hadn't got the correct number of groups from the AD server, and had
> missed
> > the group in question.
>
> Do you have the logs from the server and the client? If yes, feel free
> to send them in private mail if they are confidential, I'll try to
> find something in them.
>
> Specifying which groups are missing would help as well.
>
-- 
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] HBAC and AD users

[Jakub Hrozek]

On Wed, Jul 20, 2016 at 09:28:06AM +1000, Lachlan Musicman wrote:
> On 19 July 2016 at 16:40, Jakub Hrozek  wrote:
> 
> > On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > > I think the thing that frustrates the most is that id u...@domain.com is
> > > returning correct data on both but they can't loginand I can't even
> > > show that this is the case because now they can login. Difficult to
> > > reproduce :/
> >
> > Debugging from HBAC should at least tell you why the rules didn't
> > match...
> >
> 
> 
> Sorry, I should have been clear - the issue is exactly the same. HBAC
> rejected the user because they weren't in the correct groups, but sssd
> hadn't got the correct number of groups from the AD server, and had missed
> the group in question.

Do you have the logs from the server and the client? If yes, feel free
to send them in private mail if they are confidential, I'll try to
find something in them.

Specifying which groups are missing would help as well.

-- 
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] HBAC and AD users

[Lachlan Musicman]

On 19 July 2016 at 16:40, Jakub Hrozek  wrote:

> On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> > I think the thing that frustrates the most is that id u...@domain.com is
> > returning correct data on both but they can't loginand I can't even
> > show that this is the case because now they can login. Difficult to
> > reproduce :/
>
> Debugging from HBAC should at least tell you why the rules didn't
> match...
>


Sorry, I should have been clear - the issue is exactly the same. HBAC
rejected the user because they weren't in the correct groups, but sssd
hadn't got the correct number of groups from the AD server, and had missed
the group in question.

This is the user that reported the issue yesterday morning:

[root@vmpr-linuxidm ~]# id "lupat richard"@petermac.org.au | tr "," "\n" |
wc -l
22

Here are the relevant lines from the log.

 (Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_attrs_to_rule] (0x1000): Processing rule [Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_user_attrs_to_rule] (0x1000): Processing users for rule [Computing
Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
[Computing Cluster]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [12] groups for [Lupat Richard]
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research Bioinformatics Students
Reading Group,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Assistants,OU=Distribution Groups,OU=Research,OU=User Accounts,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf-Cluster,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=External - Exchange 2010
Users,OU=SOE & IT,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=VPN Access - General,OU=Security
Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Mac Users,OU=!Exchange
Distribution Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=Bioinf - Team,OU=!Security
Groups,OU=User Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=.Research
Bioinformatics,OU=!Exchange Distribution Groups,OU=User
Accounts,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing
CN=DM_Outlook_Find,CN=Users,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected groups second component, got Users
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN=RES_BioInformatics,OU=Department
Groups,OU=Security Groups,DC=petermac,DC=org,DC=au
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x0020): Expected cn in second component, got OU
(Tue Jul 19 10:07:53 2016) [sssd[be[unix.petermac.org.au]]]
[get_ipa_groupname] (0x1000): Parsing CN

Re: [Freeipa-users] HBAC and AD users

[Jakub Hrozek]

On Tue, Jul 19, 2016 at 11:26:02AM +1000, Lachlan Musicman wrote:
> I think the thing that frustrates the most is that id u...@domain.com is
> returning correct data on both but they can't loginand I can't even
> show that this is the case because now they can login. Difficult to
> reproduce :/

Debugging from HBAC should at least tell you why the rules didn't
match...

-- 
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] HBAC and AD users

[Lachlan Musicman]

I think the thing that frustrates the most is that id u...@domain.com is
returning correct data on both but they can't loginand I can't even
show that this is the case because now they can login. Difficult to
reproduce :/

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 19 July 2016 at 11:13, Lachlan Musicman  wrote:

> Ok, the bad news is that it didn't last. We are still having the same
> problem - HBAC is rejecting users because not all jobs are being discovered
> on the host.
>
> I turned the debug_level up to 10 as requested, but to be honest, it's
> impossible to find anything in the logs because it's so verbose - suddenly
> there are timer events everywhere. I'm going to turn it down to 7 again so
> I can actually parse it.
>
> Cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 17:56, Jakub Hrozek  wrote:
>
>> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
>> > I've updated all the relevant hosts and the FreeIPA server to the COPR
>> sssd
>> > 1.14.0 release and the problem seems to have disappeared.
>>
>> Great, but please keep an eye on the machine, the 1.14 branch is still
>> kindof fresh and we did a lot of changes.
>>
>> About the HBAC issue, did you use the default_domain_suffix previously?
>>
>> --
>> 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
>>
>
>
-- 
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] HBAC and AD users

[Lachlan Musicman]

Ok, the bad news is that it didn't last. We are still having the same
problem - HBAC is rejecting users because not all jobs are being discovered
on the host.

I turned the debug_level up to 10 as requested, but to be honest, it's
impossible to find anything in the logs because it's so verbose - suddenly
there are timer events everywhere. I'm going to turn it down to 7 again so
I can actually parse it.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek  wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > I've updated all the relevant hosts and the FreeIPA server to the COPR
> sssd
> > 1.14.0 release and the problem seems to have disappeared.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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
>
-- 
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] HBAC and AD users

[Jakub Hrozek]

On Mon, Jul 18, 2016 at 09:17:06AM +1000, Lachlan Musicman wrote:
> Previously we did have the default_domain_suffix set, but we had to unset
> it. I can't remember why we had to - something to do with
> ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
> We really wanted to use the dds => the researchers are complaining of
> broken brains due to the new concept of "ssh us...@domain.com@ipa.domain.com".
> I will need to teach ssh config.

OK, in the versions before 1.14 it was quite hard (read: impossible) to
set short names for trusted users on the clients.

On the IDM servers, you should still use long names for output, because
that's what the IPA plugins expect, but on the clients, it should be
possible to set shortnames with the full_name_format.

-- 
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] HBAC and AD users

[Lachlan Musicman]

Previously we did have the default_domain_suffix set, but we had to unset
it. I can't remember why we had to - something to do with
ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
We really wanted to use the dds => the researchers are complaining of
broken brains due to the new concept of "ssh us...@domain.com@ipa.domain.com".
I will need to teach ssh config.

Cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek  wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > I've updated all the relevant hosts and the FreeIPA server to the COPR
> sssd
> > 1.14.0 release and the problem seems to have disappeared.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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
>
-- 
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] HBAC and AD users

[Jakub Hrozek]

On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> I've updated all the relevant hosts and the FreeIPA server to the COPR sssd
> 1.14.0 release and the problem seems to have disappeared.

Great, but please keep an eye on the machine, the 1.14 branch is still
kindof fresh and we did a lot of changes.

About the HBAC issue, did you use the default_domain_suffix previously?

-- 
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] HBAC and AD users

[Lachlan Musicman]

I've updated all the relevant hosts and the FreeIPA server to the COPR sssd
1.14.0 release and the problem seems to have disappeared.

Cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 10:09, Lachlan Musicman  wrote:

> AH. I'm seeing a lot of this now.
>
> hbac_eval_user_element is returning the wrong number of groups.
>
> I just found another instance in my logs :
>
> (Fri Jul 15 08:39:04 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [23] groups for [SimpsonLachlan]
>
>
> IPA server
> [root@vmpr-linuxidm ~]# id simpsonlach...@petermac.org.au | tr "," "\n" |
> wc -l
> 41
>
> Host
> [root@papr-res-galaxy ~]# id simpsonlach...@petermac.org.au | tr "," "\n"
> |wc -l
> 41
>
>
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 09:45, Lachlan Musicman  wrote:
>
>>
>> On 14 July 2016 at 17:44, Sumit Bose  wrote:
>>
>>> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
>>> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
>>> >
>>> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
>>> >
>>> > Installed Packages
>>> > Name: ipa-server
>>> > Arch: x86_64
>>> > Version : 4.2.0
>>> > Release : 15.0.1.el7.centos.17
>>> > Size: 5.0 M
>>> > Repo: installed
>>> > >From repo   : updates
>>> > Summary : The IPA authentication server
>>> >
>>> >
>>> > Successfully joined in one way trust to AD.
>>> >
>>> > Successfully have added hosts (Centos 7, sssd 1.13.0).
>>> >
>>> >
>>> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
>>> > 
>>> > 5 HBAC rules matched
>>> > 
>>> >
>>> >   Rule name: allow_all
>>> >   User category: all
>>> >   Host category: all
>>> >   Service category: all
>>> >   Description: Allow all users to access any host from any host
>>> >   Enabled: FALSE
>>> >
>>> > ...
>>> >
>>> >   Rule name: ssh to galaxy
>>> >   Service category: all
>>> >   Description: Allows ssh to galaxy server
>>> >   Enabled: TRUE
>>> >   User Groups: ad_users
>>> >   Hosts: papr-res-galaxy.unix.petermac.org.au
>>> >
>>> >
>>> >
>>> >
>>> > With allow_all HBAC rule enabled, can login every time with
>>> >
>>> > ssh user@ad_domain@unix_host
>>> >
>>> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
>>> >
>>> > ad_users is a POSIX group with a GID. It has one member, the group
>>> >
>>> > ad_external an external group with a single, external, member
>>> >
>>> > pmc-res-ipaus...@petermac.org.au
>>> >
>>> > which is an AD group containing all the users that should have access
>>> to
>>> > the host.
>>> >
>>> >
>>> > With allow_all disabled and "ssh to galaxy" enabled, some users can
>>> login
>>> > and some can't. There is no discernable pattern that might explain why
>>> some
>>> > are discriminated against.
>>> >
>>> > Here is the test from the server:
>>> >
>>> > [root@vmpr-linuxidm ~]# ipa hbactest --user=
>>> sandsjor...@petermac.org.au
>>> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
>>> > 
>>> > Access granted: True
>>> > 
>>> >   Matched rules: ssh to galaxy
>>> >   Not matched rules: Computing Cluster
>>> >   Not matched rules: FACS Computing
>>> >
>>> > I've installed ipa-admintools on the host in question and got the same
>>> > result.
>>> >
>>> > To be on the safe side/tick all boxes, I have cleared the cache on the
>>> host
>>> > in question:
>>> >
>>> > systemctl stop sssd
>>> > sss_cache -E
>>> > systemctl start sssd
>>> >
>>> > and confirmed success with a status check.
>>> >
>>> > When the user tries to login, it fails.
>>> >
>>> > Log is here:
>>> >
>>> > http://dpaste.com/0VAFNPH
>>> >
>>> >
>>> > The top is where the negotiating starts to the best of my knowledge.
>>> >
>>> > The attempts fails, with no information that is useful to me:
>>> >
>>> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_get_category] (0x0200): Category is set to 'all'.
>>> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
>>> [ssh
>>> > to galaxy]
>>> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
>>> [ssh
>>> > to galaxy]
>>> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>>> > [hbac_eval_user_element] (0x1000): [3] groups for [
>>> > sandsjor...@petermac.org.au]
>>>
>>> According to the HBAC evaluation the user is a member of 3 groups. Is
>>> this the expected number?
>>>
>>> Can you check if 'id sandsjor...@petermac.org.au' returns the expected
>>> list of groups on the client and the IPA server? (The client does not
>>> talk to AD directly only to the IPA server, so if something is already
>>> missing on the serve

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

AH. I'm seeing a lot of this now.

hbac_eval_user_element is returning the wrong number of groups.

I just found another instance in my logs :

(Fri Jul 15 08:39:04 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [23] groups for [SimpsonLachlan]


IPA server
[root@vmpr-linuxidm ~]# id simpsonlach...@petermac.org.au | tr "," "\n" |
wc -l
41

Host
[root@papr-res-galaxy ~]# id simpsonlach...@petermac.org.au | tr "," "\n"
|wc -l
41


L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 15 July 2016 at 09:45, Lachlan Musicman  wrote:

>
> On 14 July 2016 at 17:44, Sumit Bose  wrote:
>
>> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
>> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
>> >
>> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
>> >
>> > Installed Packages
>> > Name: ipa-server
>> > Arch: x86_64
>> > Version : 4.2.0
>> > Release : 15.0.1.el7.centos.17
>> > Size: 5.0 M
>> > Repo: installed
>> > >From repo   : updates
>> > Summary : The IPA authentication server
>> >
>> >
>> > Successfully joined in one way trust to AD.
>> >
>> > Successfully have added hosts (Centos 7, sssd 1.13.0).
>> >
>> >
>> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
>> > 
>> > 5 HBAC rules matched
>> > 
>> >
>> >   Rule name: allow_all
>> >   User category: all
>> >   Host category: all
>> >   Service category: all
>> >   Description: Allow all users to access any host from any host
>> >   Enabled: FALSE
>> >
>> > ...
>> >
>> >   Rule name: ssh to galaxy
>> >   Service category: all
>> >   Description: Allows ssh to galaxy server
>> >   Enabled: TRUE
>> >   User Groups: ad_users
>> >   Hosts: papr-res-galaxy.unix.petermac.org.au
>> >
>> >
>> >
>> >
>> > With allow_all HBAC rule enabled, can login every time with
>> >
>> > ssh user@ad_domain@unix_host
>> >
>> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
>> >
>> > ad_users is a POSIX group with a GID. It has one member, the group
>> >
>> > ad_external an external group with a single, external, member
>> >
>> > pmc-res-ipaus...@petermac.org.au
>> >
>> > which is an AD group containing all the users that should have access to
>> > the host.
>> >
>> >
>> > With allow_all disabled and "ssh to galaxy" enabled, some users can
>> login
>> > and some can't. There is no discernable pattern that might explain why
>> some
>> > are discriminated against.
>> >
>> > Here is the test from the server:
>> >
>> > [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
>> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
>> > 
>> > Access granted: True
>> > 
>> >   Matched rules: ssh to galaxy
>> >   Not matched rules: Computing Cluster
>> >   Not matched rules: FACS Computing
>> >
>> > I've installed ipa-admintools on the host in question and got the same
>> > result.
>> >
>> > To be on the safe side/tick all boxes, I have cleared the cache on the
>> host
>> > in question:
>> >
>> > systemctl stop sssd
>> > sss_cache -E
>> > systemctl start sssd
>> >
>> > and confirmed success with a status check.
>> >
>> > When the user tries to login, it fails.
>> >
>> > Log is here:
>> >
>> > http://dpaste.com/0VAFNPH
>> >
>> >
>> > The top is where the negotiating starts to the best of my knowledge.
>> >
>> > The attempts fails, with no information that is useful to me:
>> >
>> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>> > [hbac_get_category] (0x0200): Category is set to 'all'.
>> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
>> [ssh
>> > to galaxy]
>> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
>> [ssh
>> > to galaxy]
>> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
>> > [hbac_eval_user_element] (0x1000): [3] groups for [
>> > sandsjor...@petermac.org.au]
>>
>> According to the HBAC evaluation the user is a member of 3 groups. Is
>> this the expected number?
>>
>> Can you check if 'id sandsjor...@petermac.org.au' returns the expected
>> list of groups on the client and the IPA server? (The client does not
>> talk to AD directly only to the IPA server, so if something is already
>> missing on the server it cannot be seen on the client as well).
>>
>>
> No, this is incorrect. He belongs to 14 groups on both the FreeIPA server
> and the host in question.
>
> [root@vmpr-linuxidm ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc
> -l
> 14
>
> [root@papr-res-galaxy ~]# id sandsjor...@petermac.org.au | tr "," "\n" |
> wc -l
> 14
>
>
>
>> Can you send me the SSSD cache file from the client
>> /var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
>> Since it might 

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

On 14 July 2016 at 17:44, Sumit Bose  wrote:

> On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> > Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> >
> > FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> >
> > Installed Packages
> > Name: ipa-server
> > Arch: x86_64
> > Version : 4.2.0
> > Release : 15.0.1.el7.centos.17
> > Size: 5.0 M
> > Repo: installed
> > >From repo   : updates
> > Summary : The IPA authentication server
> >
> >
> > Successfully joined in one way trust to AD.
> >
> > Successfully have added hosts (Centos 7, sssd 1.13.0).
> >
> >
> > [root@vmpr-linuxidm ~]# ipa hbacrule-find
> > 
> > 5 HBAC rules matched
> > 
> >
> >   Rule name: allow_all
> >   User category: all
> >   Host category: all
> >   Service category: all
> >   Description: Allow all users to access any host from any host
> >   Enabled: FALSE
> >
> > ...
> >
> >   Rule name: ssh to galaxy
> >   Service category: all
> >   Description: Allows ssh to galaxy server
> >   Enabled: TRUE
> >   User Groups: ad_users
> >   Hosts: papr-res-galaxy.unix.petermac.org.au
> >
> >
> >
> >
> > With allow_all HBAC rule enabled, can login every time with
> >
> > ssh user@ad_domain@unix_host
> >
> > If I implement a HBAC rule "ssh to galaxy" as per above, with:
> >
> > ad_users is a POSIX group with a GID. It has one member, the group
> >
> > ad_external an external group with a single, external, member
> >
> > pmc-res-ipaus...@petermac.org.au
> >
> > which is an AD group containing all the users that should have access to
> > the host.
> >
> >
> > With allow_all disabled and "ssh to galaxy" enabled, some users can login
> > and some can't. There is no discernable pattern that might explain why
> some
> > are discriminated against.
> >
> > Here is the test from the server:
> >
> > [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> > --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> > 
> > Access granted: True
> > 
> >   Matched rules: ssh to galaxy
> >   Not matched rules: Computing Cluster
> >   Not matched rules: FACS Computing
> >
> > I've installed ipa-admintools on the host in question and got the same
> > result.
> >
> > To be on the safe side/tick all boxes, I have cleared the cache on the
> host
> > in question:
> >
> > systemctl stop sssd
> > sss_cache -E
> > systemctl start sssd
> >
> > and confirmed success with a status check.
> >
> > When the user tries to login, it fails.
> >
> > Log is here:
> >
> > http://dpaste.com/0VAFNPH
> >
> >
> > The top is where the negotiating starts to the best of my knowledge.
> >
> > The attempts fails, with no information that is useful to me:
> >
> > 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_get_category] (0x0200): Category is set to 'all'.
> > 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
> [ssh
> > to galaxy]
> > 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
> [ssh
> > to galaxy]
> > 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> > [hbac_eval_user_element] (0x1000): [3] groups for [
> > sandsjor...@petermac.org.au]
>
> According to the HBAC evaluation the user is a member of 3 groups. Is
> this the expected number?
>
> Can you check if 'id sandsjor...@petermac.org.au' returns the expected
> list of groups on the client and the IPA server? (The client does not
> talk to AD directly only to the IPA server, so if something is already
> missing on the server it cannot be seen on the client as well).
>
>
No, this is incorrect. He belongs to 14 groups on both the FreeIPA server
and the host in question.

[root@vmpr-linuxidm ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc -l
14

[root@papr-res-galaxy ~]# id sandsjor...@petermac.org.au | tr "," "\n" | wc
-l
14



> Can you send me the SSSD cache file from the client
> /var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
> Since it might contain password hashes you might want to remove
> lines with 'cachedPassword' before
>
>

Ok, off list.



> bye,
> Sumit
>
>
-- 
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] HBAC and AD users

[Sumit Bose]

On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> 
> FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> 
> Installed Packages
> Name: ipa-server
> Arch: x86_64
> Version : 4.2.0
> Release : 15.0.1.el7.centos.17
> Size: 5.0 M
> Repo: installed
> >From repo   : updates
> Summary : The IPA authentication server
> 
> 
> Successfully joined in one way trust to AD.
> 
> Successfully have added hosts (Centos 7, sssd 1.13.0).
> 
> 
> [root@vmpr-linuxidm ~]# ipa hbacrule-find
> 
> 5 HBAC rules matched
> 
> 
>   Rule name: allow_all
>   User category: all
>   Host category: all
>   Service category: all
>   Description: Allow all users to access any host from any host
>   Enabled: FALSE
> 
> ...
> 
>   Rule name: ssh to galaxy
>   Service category: all
>   Description: Allows ssh to galaxy server
>   Enabled: TRUE
>   User Groups: ad_users
>   Hosts: papr-res-galaxy.unix.petermac.org.au
> 
> 
> 
> 
> With allow_all HBAC rule enabled, can login every time with
> 
> ssh user@ad_domain@unix_host
> 
> If I implement a HBAC rule "ssh to galaxy" as per above, with:
> 
> ad_users is a POSIX group with a GID. It has one member, the group
> 
> ad_external an external group with a single, external, member
> 
> pmc-res-ipaus...@petermac.org.au
> 
> which is an AD group containing all the users that should have access to
> the host.
> 
> 
> With allow_all disabled and "ssh to galaxy" enabled, some users can login
> and some can't. There is no discernable pattern that might explain why some
> are discriminated against.
> 
> Here is the test from the server:
> 
> [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> 
> Access granted: True
> 
>   Matched rules: ssh to galaxy
>   Not matched rules: Computing Cluster
>   Not matched rules: FACS Computing
> 
> I've installed ipa-admintools on the host in question and got the same
> result.
> 
> To be on the safe side/tick all boxes, I have cleared the cache on the host
> in question:
> 
> systemctl stop sssd
> sss_cache -E
> systemctl start sssd
> 
> and confirmed success with a status check.
> 
> When the user tries to login, it fails.
> 
> Log is here:
> 
> http://dpaste.com/0VAFNPH
> 
> 
> The top is where the negotiating starts to the best of my knowledge.
> 
> The attempts fails, with no information that is useful to me:
> 
> 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_get_category] (0x0200): Category is set to 'all'.
> 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [ssh
> to galaxy]
> 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [ssh
> to galaxy]
> 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [3] groups for [
> sandsjor...@petermac.org.au]

According to the HBAC evaluation the user is a member of 3 groups. Is
this the expected number?

Can you check if 'id sandsjor...@petermac.org.au' returns the expected
list of groups on the client and the IPA server? (The client does not
talk to AD directly only to the IPA server, so if something is already
missing on the server it cannot be seen on the client as well).

Can you send me the SSSD cache file from the client
/var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
Since it might contain password hashes you might want to remove
lines with 'cachedPassword' before

bye,
Sumit


> 234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
> 235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, )
> [Success (Permission denied)]
> 236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au]
> 237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au]
> 
> 
> Cheers
> L.
> 
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 12 July 2016 at 09:08, Lachlan Musicman  wrote:
> 
> > Alex, Sumit,
> >
> > Which log levels would you recommend for sssd to help debug this issue?
> >
> > We've been using 7, but I just realised that it's not an increasing scale
> > but bitmasked...
> >
> > cheers
> > L.
> >
> > --
> > The most dangerous phrase in the language is, "We've always done it this
> > way."
> >
> > - Grace Hopper
> >
> > On 11 July 2016 at 17:15, Sumit Bose  wrote:
> >
> >> On Mon, Jul 11, 2016 at 04:5

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

Ok, I have some logs of sssd 1.13.0 not working. Same values as before:

FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156

Installed Packages
Name: ipa-server
Arch: x86_64
Version : 4.2.0
Release : 15.0.1.el7.centos.17
Size: 5.0 M
Repo: installed
>From repo   : updates
Summary : The IPA authentication server


Successfully joined in one way trust to AD.

Successfully have added hosts (Centos 7, sssd 1.13.0).


[root@vmpr-linuxidm ~]# ipa hbacrule-find

5 HBAC rules matched


  Rule name: allow_all
  User category: all
  Host category: all
  Service category: all
  Description: Allow all users to access any host from any host
  Enabled: FALSE

...

  Rule name: ssh to galaxy
  Service category: all
  Description: Allows ssh to galaxy server
  Enabled: TRUE
  User Groups: ad_users
  Hosts: papr-res-galaxy.unix.petermac.org.au




With allow_all HBAC rule enabled, can login every time with

ssh user@ad_domain@unix_host

If I implement a HBAC rule "ssh to galaxy" as per above, with:

ad_users is a POSIX group with a GID. It has one member, the group

ad_external an external group with a single, external, member

pmc-res-ipaus...@petermac.org.au

which is an AD group containing all the users that should have access to
the host.


With allow_all disabled and "ssh to galaxy" enabled, some users can login
and some can't. There is no discernable pattern that might explain why some
are discriminated against.

Here is the test from the server:

[root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
--host=papr-res-galaxy.unix.petermac.org.au --service=sshd

Access granted: True

  Matched rules: ssh to galaxy
  Not matched rules: Computing Cluster
  Not matched rules: FACS Computing

I've installed ipa-admintools on the host in question and got the same
result.

To be on the safe side/tick all boxes, I have cleared the cache on the host
in question:

systemctl stop sssd
sss_cache -E
systemctl start sssd

and confirmed success with a status check.

When the user tries to login, it fails.

Log is here:

http://dpaste.com/0VAFNPH


The top is where the negotiating starts to the best of my knowledge.

The attempts fails, with no information that is useful to me:

230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_get_category] (0x0200): Category is set to 'all'.
231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [ssh
to galaxy]
232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [ssh
to galaxy]
233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[hbac_eval_user_element] (0x1000): [3] groups for [
sandsjor...@petermac.org.au]
234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 6, )
[Success (Permission denied)]
236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au]
237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
[be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au]


Cheers
L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 12 July 2016 at 09:08, Lachlan Musicman  wrote:

> Alex, Sumit,
>
> Which log levels would you recommend for sssd to help debug this issue?
>
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...
>
> cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 11 July 2016 at 17:15, Sumit Bose  wrote:
>
>> On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
>> > On 11 July 2016 at 16:44, Alexander Bokovoy 
>> wrote:
>> >
>> > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
>> > >
>> > >> Hola,
>> > >>
>> > >> Centos 7, up to date.
>> > >>
>> > >> [root@linuxidm ~]# ipa --version
>> > >> VERSION: 4.2.0, API_VERSION: 2.156
>> > >>
>> > >> One way trust is successfully established, can login with
>> > >>
>> > >> ssh usern...@domain1.com@server1.domain2.com
>> > >>
>> > >> Am testing to get HBAC to work.
>> > >>
>> > >> I've noticed that with the Allow All rule in effect, the following
>> set up
>> > >> is sufficient:
>> > >>
>> > >> add external group "ad_external"
>> > >> add internal group, "ad_internal", add ad_external as a group member
>> of
>> > >> ad_internal
>> > >>
>> > >> AD users can now successfully login to any server.
>> > >>
>> > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
>> > >> needed to complete the extra step of adding AD users explicitl

Re: [Freeipa-users] HBAC and AD users

[Sumit Bose]

On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman wrote:
> Alex, Sumit,
> 
> Which log levels would you recommend for sssd to help debug this issue?
> 
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...

It is both 0-9 is increasing scale while values above 16 are treated as
bitmask. Please just use 9 to get all messages.

bye,
Sumit

> 
> cheers
> L.
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 11 July 2016 at 17:15, Sumit Bose  wrote:
> 
> > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > > On 11 July 2016 at 16:44, Alexander Bokovoy  wrote:
> > >
> > > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> > > >
> > > >> Hola,
> > > >>
> > > >> Centos 7, up to date.
> > > >>
> > > >> [root@linuxidm ~]# ipa --version
> > > >> VERSION: 4.2.0, API_VERSION: 2.156
> > > >>
> > > >> One way trust is successfully established, can login with
> > > >>
> > > >> ssh usern...@domain1.com@server1.domain2.com
> > > >>
> > > >> Am testing to get HBAC to work.
> > > >>
> > > >> I've noticed that with the Allow All rule in effect, the following
> > set up
> > > >> is sufficient:
> > > >>
> > > >> add external group "ad_external"
> > > >> add internal group, "ad_internal", add ad_external as a group member
> > of
> > > >> ad_internal
> > > >>
> > > >> AD users can now successfully login to any server.
> > > >>
> > > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> > > >> needed to complete the extra step of adding AD users explicitly to the
> > > >> "external member" group of the external group.
> >
> > yes, this is expected you either have to add AD users or groups to the
> > external groups.
> >
> > > >>
> > > >> I also note that this seems to be explicitly user based, not group
> > based?
> > > >> IE, I can add lach...@domain1.com to the external members of
> > ad_external
> > > >> and that works, but adding the group server_adm...@domain1.com (as
> > seen
> > > >> in
> > > >> `id lach...@domain1.com`) doesn't allow all members access.
> >
> > Since it looks you are using FreeIPA 4.2 you might hit
> > https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
> > the part where the HBAC rules are evaluated would help to understand the
> > issue better.
> >
> > > >>
> > > >> Does that sound correct?
> > > >>
> > > > No, it does not.
> > > > HBAC evaluation and external group merging/resolution is done by SSSD.
> > > > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > > > that can help understanding what happens there.
> > > >
> > > > What SSSD version do you have on both IPA client and IPA server?
> > >
> > >
> > >
> > > 1.13.0 on both client and server.
> > >
> > > To be honest, we have ratcheted up the logs and it doesn't help that
> > much.
> > > We just got lots of "unsupported PAM command [249]"
> >
> > This is unrelated, I assume this happens when trying to store the hashed
> > password to the cache. This message is remove in newer releases.
> >
> > bye,
> > Sumit
> >
> > >
> > > Cheers
> > > L.
> >
> > > --
> > > 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
> >
> >

> -- 
> 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

-- 
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] HBAC and AD users

[Lachlan Musicman]

Alex, Sumit,

Which log levels would you recommend for sssd to help debug this issue?

We've been using 7, but I just realised that it's not an increasing scale
but bitmasked...

cheers
L.

--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 11 July 2016 at 17:15, Sumit Bose  wrote:

> On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > On 11 July 2016 at 16:44, Alexander Bokovoy  wrote:
> >
> > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> > >
> > >> Hola,
> > >>
> > >> Centos 7, up to date.
> > >>
> > >> [root@linuxidm ~]# ipa --version
> > >> VERSION: 4.2.0, API_VERSION: 2.156
> > >>
> > >> One way trust is successfully established, can login with
> > >>
> > >> ssh usern...@domain1.com@server1.domain2.com
> > >>
> > >> Am testing to get HBAC to work.
> > >>
> > >> I've noticed that with the Allow All rule in effect, the following
> set up
> > >> is sufficient:
> > >>
> > >> add external group "ad_external"
> > >> add internal group, "ad_internal", add ad_external as a group member
> of
> > >> ad_internal
> > >>
> > >> AD users can now successfully login to any server.
> > >>
> > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> > >> needed to complete the extra step of adding AD users explicitly to the
> > >> "external member" group of the external group.
>
> yes, this is expected you either have to add AD users or groups to the
> external groups.
>
> > >>
> > >> I also note that this seems to be explicitly user based, not group
> based?
> > >> IE, I can add lach...@domain1.com to the external members of
> ad_external
> > >> and that works, but adding the group server_adm...@domain1.com (as
> seen
> > >> in
> > >> `id lach...@domain1.com`) doesn't allow all members access.
>
> Since it looks you are using FreeIPA 4.2 you might hit
> https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
> the part where the HBAC rules are evaluated would help to understand the
> issue better.
>
> > >>
> > >> Does that sound correct?
> > >>
> > > No, it does not.
> > > HBAC evaluation and external group merging/resolution is done by SSSD.
> > > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > > that can help understanding what happens there.
> > >
> > > What SSSD version do you have on both IPA client and IPA server?
> >
> >
> >
> > 1.13.0 on both client and server.
> >
> > To be honest, we have ratcheted up the logs and it doesn't help that
> much.
> > We just got lots of "unsupported PAM command [249]"
>
> This is unrelated, I assume this happens when trying to store the hashed
> password to the cache. This message is remove in newer releases.
>
> bye,
> Sumit
>
> >
> > Cheers
> > L.
>
> > --
> > 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
>
>
-- 
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] HBAC and AD users

[Sumit Bose]

On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> On 11 July 2016 at 16:44, Alexander Bokovoy  wrote:
> 
> > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> >
> >> Hola,
> >>
> >> Centos 7, up to date.
> >>
> >> [root@linuxidm ~]# ipa --version
> >> VERSION: 4.2.0, API_VERSION: 2.156
> >>
> >> One way trust is successfully established, can login with
> >>
> >> ssh usern...@domain1.com@server1.domain2.com
> >>
> >> Am testing to get HBAC to work.
> >>
> >> I've noticed that with the Allow All rule in effect, the following set up
> >> is sufficient:
> >>
> >> add external group "ad_external"
> >> add internal group, "ad_internal", add ad_external as a group member of
> >> ad_internal
> >>
> >> AD users can now successfully login to any server.
> >>
> >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> >> needed to complete the extra step of adding AD users explicitly to the
> >> "external member" group of the external group.

yes, this is expected you either have to add AD users or groups to the
external groups.

> >>
> >> I also note that this seems to be explicitly user based, not group based?
> >> IE, I can add lach...@domain1.com to the external members of ad_external
> >> and that works, but adding the group server_adm...@domain1.com (as seen
> >> in
> >> `id lach...@domain1.com`) doesn't allow all members access.

Since it looks you are using FreeIPA 4.2 you might hit
https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
the part where the HBAC rules are evaluated would help to understand the
issue better.

> >>
> >> Does that sound correct?
> >>
> > No, it does not.
> > HBAC evaluation and external group merging/resolution is done by SSSD.
> > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > that can help understanding what happens there.
> >
> > What SSSD version do you have on both IPA client and IPA server?
> 
> 
> 
> 1.13.0 on both client and server.
> 
> To be honest, we have ratcheted up the logs and it doesn't help that much.
> We just got lots of "unsupported PAM command [249]"

This is unrelated, I assume this happens when trying to store the hashed
password to the cache. This message is remove in newer releases.

bye,
Sumit

> 
> Cheers
> L.

> -- 
> 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

-- 
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] HBAC and AD users

[Lachlan Musicman]

On 11 July 2016 at 16:44, Alexander Bokovoy  wrote:

> On Mon, 11 Jul 2016, Lachlan Musicman wrote:
>
>> Hola,
>>
>> Centos 7, up to date.
>>
>> [root@linuxidm ~]# ipa --version
>> VERSION: 4.2.0, API_VERSION: 2.156
>>
>> One way trust is successfully established, can login with
>>
>> ssh usern...@domain1.com@server1.domain2.com
>>
>> Am testing to get HBAC to work.
>>
>> I've noticed that with the Allow All rule in effect, the following set up
>> is sufficient:
>>
>> add external group "ad_external"
>> add internal group, "ad_internal", add ad_external as a group member of
>> ad_internal
>>
>> AD users can now successfully login to any server.
>>
>> When I tried to set up an HBAC, I couldn't get that set up to work, I
>> needed to complete the extra step of adding AD users explicitly to the
>> "external member" group of the external group.
>>
>> I also note that this seems to be explicitly user based, not group based?
>> IE, I can add lach...@domain1.com to the external members of ad_external
>> and that works, but adding the group server_adm...@domain1.com (as seen
>> in
>> `id lach...@domain1.com`) doesn't allow all members access.
>>
>> Does that sound correct?
>>
> No, it does not.
> HBAC evaluation and external group merging/resolution is done by SSSD.
> Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> that can help understanding what happens there.
>
> What SSSD version do you have on both IPA client and IPA server?



1.13.0 on both client and server.

To be honest, we have ratcheted up the logs and it doesn't help that much.
We just got lots of "unsupported PAM command [249]"

Cheers
L.
-- 
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] HBAC and AD users

[Alexander Bokovoy]

On Mon, 11 Jul 2016, Lachlan Musicman wrote:

Hola,

Centos 7, up to date.

[root@linuxidm ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

One way trust is successfully established, can login with

ssh usern...@domain1.com@server1.domain2.com

Am testing to get HBAC to work.

I've noticed that with the Allow All rule in effect, the following set up
is sufficient:

add external group "ad_external"
add internal group, "ad_internal", add ad_external as a group member of
ad_internal

AD users can now successfully login to any server.

When I tried to set up an HBAC, I couldn't get that set up to work, I
needed to complete the extra step of adding AD users explicitly to the
"external member" group of the external group.

I also note that this seems to be explicitly user based, not group based?
IE, I can add lach...@domain1.com to the external members of ad_external
and that works, but adding the group server_adm...@domain1.com (as seen in
`id lach...@domain1.com`) doesn't allow all members access.

Does that sound correct?

No, it does not.
HBAC evaluation and external group merging/resolution is done by SSSD.
Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
that can help understanding what happens there.

What SSSD version do you have on both IPA client and IPA server?
--
/ Alexander Bokovoy

--
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] HBAC and AD users

[Lachlan Musicman]

Hola,

Centos 7, up to date.

[root@linuxidm ~]# ipa --version
VERSION: 4.2.0, API_VERSION: 2.156

One way trust is successfully established, can login with

ssh usern...@domain1.com@server1.domain2.com

Am testing to get HBAC to work.

I've noticed that with the Allow All rule in effect, the following set up
is sufficient:

add external group "ad_external"
add internal group, "ad_internal", add ad_external as a group member of
ad_internal

AD users can now successfully login to any server.

When I tried to set up an HBAC, I couldn't get that set up to work, I
needed to complete the extra step of adding AD users explicitly to the
"external member" group of the external group.

I also note that this seems to be explicitly user based, not group based?
IE, I can add lach...@domain1.com to the external members of ad_external
and that works, but adding the group server_adm...@domain1.com (as seen in
`id lach...@domain1.com`) doesn't allow all members access.

Does that sound correct?

L.


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] HBAC rules for NFS

[Joanna Delaporte]

Hi Alexander,

Thanks for the link. I read through it again, and I am still stuck on the
rpcgss service on the server...I don't know how to properly restart it. The
service in the documents is service nfs-secure-server enable (FC16), or
rpcsvcgssd.service (RH7), but I cannot enable using those.

I killed rpc.gssd process on the client and restarted manually with
rpc.gssd -vvv, which gave me more output. There is a flag set in
/etc/sysconfig/nfs which should have already been giving that output, but
it never took effect, even though I restarted nfs-server and
nfs-secure-server. What is the right way to restart rpcgssd.service and
rpcsvcgssd.service?

Anyway, after manually killing and executing rpc.gssd, the homedir
automounts with krb5p when I ssh to the machine (yay - first time!), but
the files are owned by nobody. I cannot access the files as the owner. The
UID of the file owner is low (between 500-1000), so I had to change the
user's UID just to be able to login (<1000 is blocked by PAM). Maybe the
fact that the user with a matching UID doesn't exist is causing a problem
in mapping the files' owner to a user? If so, how do I most efficiently map
the name of the file owner to the user with a different numerical UID? I
had hoped the kerberos auth might handle this for me.

The homedir does not mount when I su from root (not particularly a problem,
but it was muddling the issue). This clued me in: rpc.gssd[9928]: No key
table entry found for root/nfsclient.domain.tld.

Thank you!
Joanna

On Fri, Jul 1, 2016 at 3:59 PM, Alexander Bokovoy 
wrote:

> On Fri, 01 Jul 2016, Joanna Delaporte wrote:
>
>> I am having trouble using NFSv4 via krb5 on my new IPA realm, and I am
>> starting to wonder if I don't have HBAC rules set up correctly.  I
>> installed freeIPA with --no_hbac_allow.
>>
>> I have an HBAC service defined as an nfs service:
>> $ ipa hbacsvc-add --desc="NFS service" nfs
>>
>> I have an HBAC rule that allows all users to access all services on a
>> group
>> of hosts. My nfsclient is in that group.
>>
>> Is that enough to allow users rights to mount nfs shares? Do I need some
>> sort of HBAC between the nfsclient and the nfsserver?
>>
> HBAC is not involved at all for NFS use. Remember, HBAC checks are run
> by SSSD when it is called by PAM session setup. There is nothing like
> that for NFS mounts.
>
> Have you read http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA ?
>
>
> --
> / Alexander Bokovoy
>



-- 


Joanna Delaporte
Linux Systems Administrator | Parkland College
joannadelapo...@gmail.com
-- 
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] HBAC rules for NFS

[Alexander Bokovoy]

On Fri, 01 Jul 2016, Joanna Delaporte wrote:

I am having trouble using NFSv4 via krb5 on my new IPA realm, and I am
starting to wonder if I don't have HBAC rules set up correctly.  I
installed freeIPA with --no_hbac_allow.

I have an HBAC service defined as an nfs service:
$ ipa hbacsvc-add --desc="NFS service" nfs

I have an HBAC rule that allows all users to access all services on a group
of hosts. My nfsclient is in that group.

Is that enough to allow users rights to mount nfs shares? Do I need some
sort of HBAC between the nfsclient and the nfsserver?

HBAC is not involved at all for NFS use. Remember, HBAC checks are run
by SSSD when it is called by PAM session setup. There is nothing like
that for NFS mounts.

Have you read http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA ?


--
/ Alexander Bokovoy

--
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] HBAC rules for NFS

[Joanna Delaporte]

I am having trouble using NFSv4 via krb5 on my new IPA realm, and I am
starting to wonder if I don't have HBAC rules set up correctly.  I
installed freeIPA with --no_hbac_allow.

I have an HBAC service defined as an nfs service:
$ ipa hbacsvc-add --desc="NFS service" nfs

I have an HBAC rule that allows all users to access all services on a group
of hosts. My nfsclient is in that group.

Is that enough to allow users rights to mount nfs shares? Do I need some
sort of HBAC between the nfsclient and the nfsserver?

Thanks! Joanna

-- 


Joanna Delaporte
Linux Systems Administrator | Parkland College
joannadelapo...@gmail.com
-- 
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Wed, May 18, 2016 at 11:17:05PM +, Simpson Lachlan wrote:
> > -Original Message-
> > From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> > boun...@redhat.com] On Behalf Of Jakub Hrozek
> > Sent: Wednesday, 18 May 2016 5:40 PM
> > To: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] HBAC access denied, all AD groups not detected
> > 
> > On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote:
> > > Hmmm, I also now see
> > >
> > > https://fedorahosted.org/sssd/ticket/2642
> > > and
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1217127
> > >
> > > Versions being run:
> > >
> > > sssd-client-1.13.0-40.el7_2.4.x86_64
> > > sssd-ad-1.13.0-40.el7_2.4.x86_64
> > > sssd-proxy-1.13.0-40.el7_2.4.x86_64
> > > sssd-1.13.0-40.el7_2.4.x86_64
> > > sssd-common-1.13.0-40.el7_2.4.x86_64
> > > sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> > > sssd-ipa-1.13.0-40.el7_2.4.x86_64
> > > sssd-ldap-1.13.0-40.el7_2.4.x86_64
> > > python-sssdconfig-1.13.0-40.el7_2.4.noarch
> > > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> > > sssd-krb5-1.13.0-40.el7_2.4.x86_64
> > >
> > > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
> > 
> > The reason I asked about the server versions is
> > https://bugzilla.redhat.com/show_bug.cgi?id=1304333
> > 
> > I'm not too familiar with how the centos versioning works, can you check if 
> > that
> > bug is mentioned in the rpm changelog?
> 
> 
> "You are not authorized to access bug #1304333." :(
> This email (including any attachments or links) may contain 
> confidential and/or legally privileged information and is 
> intended only to be read or used by the addressee.  If you 
> are not the intended addressee, any use, distribution, 
> disclosure or copying of this email is strictly 
> prohibited.  
> Confidentiality and legal privilege attached to this email 
> (including any attachments) are not waived or lost by 
> reason of its mistaken delivery to you.
> If you have received this email in error, please delete it 
> and notify us immediately by telephone or email.  Peter 
> MacCallum Cancer Centre provides no guarantee that this 
> transmission is free of virus or that it has not been 
> intercepted or altered and will not be liable for any delay 
> in its receipt.

Ah, sorry, there must have been some private customer information in the
bugzilla. Here is the corresponding upstream ticket:
https://fedorahosted.org/freeipa/ticket/5573

-- 
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] HBAC access denied, all AD groups not detected

[Simpson Lachlan]

> -Original Message-
> From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-
> boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: Wednesday, 18 May 2016 5:40 PM
> To: freeipa-users@redhat.com
> Subject: Re: [Freeipa-users] HBAC access denied, all AD groups not detected
> 
> On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote:
> > Hmmm, I also now see
> >
> > https://fedorahosted.org/sssd/ticket/2642
> > and
> > https://bugzilla.redhat.com/show_bug.cgi?id=1217127
> >
> > Versions being run:
> >
> > sssd-client-1.13.0-40.el7_2.4.x86_64
> > sssd-ad-1.13.0-40.el7_2.4.x86_64
> > sssd-proxy-1.13.0-40.el7_2.4.x86_64
> > sssd-1.13.0-40.el7_2.4.x86_64
> > sssd-common-1.13.0-40.el7_2.4.x86_64
> > sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> > sssd-ipa-1.13.0-40.el7_2.4.x86_64
> > sssd-ldap-1.13.0-40.el7_2.4.x86_64
> > python-sssdconfig-1.13.0-40.el7_2.4.noarch
> > sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> > sssd-krb5-1.13.0-40.el7_2.4.x86_64
> >
> > ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
> 
> The reason I asked about the server versions is
> https://bugzilla.redhat.com/show_bug.cgi?id=1304333
> 
> I'm not too familiar with how the centos versioning works, can you check if 
> that
> bug is mentioned in the rpm changelog?


"You are not authorized to access bug #1304333." :(
This email (including any attachments or links) may contain 
confidential and/or legally privileged information and is 
intended only to be read or used by the addressee.  If you 
are not the intended addressee, any use, distribution, 
disclosure or copying of this email is strictly 
prohibited.  
Confidentiality and legal privilege attached to this email 
(including any attachments) are not waived or lost by 
reason of its mistaken delivery to you.
If you have received this email in error, please delete it 
and notify us immediately by telephone or email.  Peter 
MacCallum Cancer Centre provides no guarantee that this 
transmission is free of virus or that it has not been 
intercepted or altered and will not be liable for any delay 
in its receipt.


-- 
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] HBAC access denied, all AD groups not detected

[Alexander Bokovoy]

On Wed, 18 May 2016, Jakub Hrozek wrote:

On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote:

Hmmm, I also now see

https://fedorahosted.org/sssd/ticket/2642
and
https://bugzilla.redhat.com/show_bug.cgi?id=1217127

Versions being run:

sssd-client-1.13.0-40.el7_2.4.x86_64
sssd-ad-1.13.0-40.el7_2.4.x86_64
sssd-proxy-1.13.0-40.el7_2.4.x86_64
sssd-1.13.0-40.el7_2.4.x86_64
sssd-common-1.13.0-40.el7_2.4.x86_64
sssd-common-pac-1.13.0-40.el7_2.4.x86_64
sssd-ipa-1.13.0-40.el7_2.4.x86_64
sssd-ldap-1.13.0-40.el7_2.4.x86_64
python-sssdconfig-1.13.0-40.el7_2.4.noarch
sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
sssd-krb5-1.13.0-40.el7_2.4.x86_64

ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64


The reason I asked about the server versions is
https://bugzilla.redhat.com/show_bug.cgi?id=1304333

I'm not too familiar with how the centos versioning works, can you check
if that bug is mentioned in the rpm changelog?

No, these packages are not at the level where all known membership bugs
were fixed.

RHEL 7.2 build should be ipa-4.2.0-15.el7_2.15. A corresponding CentOS
build is already available in updates and it is ipa-4.2.0-15.el7.centos.15

--
/ Alexander Bokovoy

--
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Wed, May 18, 2016 at 08:35:14AM +1000, Lachlan Musicman wrote:
> Hmmm, I also now see
> 
> https://fedorahosted.org/sssd/ticket/2642
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=1217127
> 
> Versions being run:
> 
> sssd-client-1.13.0-40.el7_2.4.x86_64
> sssd-ad-1.13.0-40.el7_2.4.x86_64
> sssd-proxy-1.13.0-40.el7_2.4.x86_64
> sssd-1.13.0-40.el7_2.4.x86_64
> sssd-common-1.13.0-40.el7_2.4.x86_64
> sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> sssd-ipa-1.13.0-40.el7_2.4.x86_64
> sssd-ldap-1.13.0-40.el7_2.4.x86_64
> python-sssdconfig-1.13.0-40.el7_2.4.noarch
> sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> sssd-krb5-1.13.0-40.el7_2.4.x86_64
> 
> ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64

The reason I asked about the server versions is
https://bugzilla.redhat.com/show_bug.cgi?id=1304333

I'm not too familiar with how the centos versioning works, can you check
if that bug is mentioned in the rpm changelog?

-- 
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Wed, May 18, 2016 at 09:46:49AM +1000, Lachlan Musicman wrote:
> It's worth noting that, in difference to the bug report:
> 
> 1. We aren't making changes to the overrides. The overrides exist, they
> just aren't propagating evenly or consistently.
> 2. We are seeing these errors in the various logs:
> 
> 
> sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]]
> [sysdb_delete_group] (0x0400): Error: 2 (No such file or directory)
> sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> 
> 
> krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8929
> [k5c_send_data] (0x0200): Received error code 0
> krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8931
> [k5c_send_data] (0x0200): Received error code 1432158214
> 
> sssd_nss.log:Error: 3, 0, Account info lookup failed
> sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply]
> (0x1000): Got reply from Data Provider - DP error code: 3 errno: 22 error
> message: Account info lookup failed
> sssd_nss.log:Error: 3, 22, Account info lookup failed
> sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply]
> (0x1000): Got reply from Data Provider - DP error code: 3 errno: 0 error
> message: Account info lookup failed

You need to look into the failures in the domain log that happened in
the same time as these. Some failures are recoverable, in some other
cases we're just reporting failure even if we just didn't match any
entry (yes, that a subtle bug we should fix).

-- 
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] HBAC access denied, all AD groups not detected

[Lachlan Musicman]

It's worth noting that, in difference to the bug report:

1. We aren't making changes to the overrides. The overrides exist, they
just aren't propagating evenly or consistently.
2. We are seeing these errors in the various logs:


sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]]
[sysdb_delete_group] (0x0400): Error: 2 (No such file or directory)
sssd_DOMAIN.log:(Wed May 18 09:00:01 2016) [sssd[be[DOMAIN]]]
[sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)


krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8929
[k5c_send_data] (0x0200): Received error code 0
krb5_child.log:(Wed May 18 09:12:30 2016) [[sssd[krb5_child[8931
[k5c_send_data] (0x0200): Received error code 1432158214

sssd_nss.log:Error: 3, 0, Account info lookup failed
sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply]
(0x1000): Got reply from Data Provider - DP error code: 3 errno: 22 error
message: Account info lookup failed
sssd_nss.log:Error: 3, 22, Account info lookup failed
sssd_nss.log:(Wed May 18 09:01:04 2016) [sssd[nss]] [sss_dp_get_reply]
(0x1000): Got reply from Data Provider - DP error code: 3 errno: 0 error
message: Account info lookup failed


cheers
L.



--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 18 May 2016 at 08:35, Lachlan Musicman  wrote:

> Hmmm, I also now see
>
> https://fedorahosted.org/sssd/ticket/2642
> and
> https://bugzilla.redhat.com/show_bug.cgi?id=1217127
>
> Versions being run:
>
> sssd-client-1.13.0-40.el7_2.4.x86_64
> sssd-ad-1.13.0-40.el7_2.4.x86_64
> sssd-proxy-1.13.0-40.el7_2.4.x86_64
> sssd-1.13.0-40.el7_2.4.x86_64
> sssd-common-1.13.0-40.el7_2.4.x86_64
> sssd-common-pac-1.13.0-40.el7_2.4.x86_64
> sssd-ipa-1.13.0-40.el7_2.4.x86_64
> sssd-ldap-1.13.0-40.el7_2.4.x86_64
> python-sssdconfig-1.13.0-40.el7_2.4.noarch
> sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
> sssd-krb5-1.13.0-40.el7_2.4.x86_64
>
> ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 17 May 2016 at 22:34, Jakub Hrozek  wrote:
>
>> On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote:
>> > FWIW,
>> >
>> > We are seeing the issues that are described here:
>> >
>> >
>> https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html
>> >
>> > I was about to write when I found this, it explains exactly what I am
>> > seeing - right down to the "impossible to reproduce because it's so
>> > (seemingly) random".
>> >
>> >
>> > I am about to read up on the SSSD trouble shooting in order to up the
>> logs
>> > &etc, but here is some output I can share - note that this all happened
>> in
>> > ~5 minutes. As you can see, clearing the cache has various unpredictable
>> > effects. Both users should return the same list of groups. This was
>> > performed on a FreeIPA client.
>>
>> There were some bugs related to external groups, what server and client
>> packages version are you running?
>>
>> --
>> 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
>>
>
>
-- 
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] HBAC access denied, all AD groups not detected

[Lachlan Musicman]

Hmmm, I also now see

https://fedorahosted.org/sssd/ticket/2642
and
https://bugzilla.redhat.com/show_bug.cgi?id=1217127

Versions being run:

sssd-client-1.13.0-40.el7_2.4.x86_64
sssd-ad-1.13.0-40.el7_2.4.x86_64
sssd-proxy-1.13.0-40.el7_2.4.x86_64
sssd-1.13.0-40.el7_2.4.x86_64
sssd-common-1.13.0-40.el7_2.4.x86_64
sssd-common-pac-1.13.0-40.el7_2.4.x86_64
sssd-ipa-1.13.0-40.el7_2.4.x86_64
sssd-ldap-1.13.0-40.el7_2.4.x86_64
python-sssdconfig-1.13.0-40.el7_2.4.noarch
sssd-krb5-common-1.13.0-40.el7_2.4.x86_64
sssd-krb5-1.13.0-40.el7_2.4.x86_64

ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.6.1.x86_64


--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper

On 17 May 2016 at 22:34, Jakub Hrozek  wrote:

> On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote:
> > FWIW,
> >
> > We are seeing the issues that are described here:
> >
> >
> https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html
> >
> > I was about to write when I found this, it explains exactly what I am
> > seeing - right down to the "impossible to reproduce because it's so
> > (seemingly) random".
> >
> >
> > I am about to read up on the SSSD trouble shooting in order to up the
> logs
> > &etc, but here is some output I can share - note that this all happened
> in
> > ~5 minutes. As you can see, clearing the cache has various unpredictable
> > effects. Both users should return the same list of groups. This was
> > performed on a FreeIPA client.
>
> There were some bugs related to external groups, what server and client
> packages version are you running?
>
> --
> 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
>
-- 
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Tue, May 17, 2016 at 03:08:37PM +1000, Lachlan Musicman wrote:
> FWIW,
> 
> We are seeing the issues that are described here:
> 
> https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html
> 
> I was about to write when I found this, it explains exactly what I am
> seeing - right down to the "impossible to reproduce because it's so
> (seemingly) random".
> 
> 
> I am about to read up on the SSSD trouble shooting in order to up the logs
> &etc, but here is some output I can share - note that this all happened in
> ~5 minutes. As you can see, clearing the cache has various unpredictable
> effects. Both users should return the same list of groups. This was
> performed on a FreeIPA client.

There were some bugs related to external groups, what server and client
packages version are you running?

-- 
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] HBAC access denied, all AD groups not detected

[Lachlan Musicman]

FWIW,

We are seeing the issues that are described here:

https://www.redhat.com/archives/freeipa-users/2015-December/msg00046.html

I was about to write when I found this, it explains exactly what I am
seeing - right down to the "impossible to reproduce because it's so
(seemingly) random".


I am about to read up on the SSSD trouble shooting in order to up the logs
&etc, but here is some output I can share - note that this all happened in
~5 minutes. As you can see, clearing the cache has various unpredictable
effects. Both users should return the same list of groups. This was
performed on a FreeIPA client.

[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10011(facs-comp...@unix.petermac.org.au)
10004(bioinf-c...@unix.petermac.org.au)
10005(rcf-st...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd
[root@emts-facs ~]# rm -rf /var/lib/sss/db/*
[root@emts-facs ~]# systemctl start sssd
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)
[root@emts-facs ~]# systemctl stop sssd; sss_cache -E; systemctl start sssd
[root@emts-facs ~]# id "ellul jason" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
[root@emts-facs ~]# id "simpsonlachlan" | tr "," "\n" | grep 10
1750673801(external - exchange 2010 us...@petermac.org.au)
10007(cluster-u...@unix.petermac.org.au)



Cheers
L.




--
The most dangerous phrase in the language is, "We've always done it this
way."

- Grace Hopper
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

and here is my sssd debug log from client side

http://pastebin.com/ud2q3FR5

On Sat, Apr 30, 2016 at 10:06 AM, Ben .T.George 
wrote:

> Hi
>
> Adding this this.
>
> in AD i habe added 2 users , ben and jude. In my HBAC rule, i pointed this
> specific external group and (were these users)
>
> but while checking the rule from IPA server using hbactest, both users
> test passes and showing one rol. but in actual only ben can able to login
> to client machine , while jude cannot.
>
> [root@freeipa ~]# ipa hbactest --user *b...@kwttestdc.com.kw
> * --host client.kwttestdc.com.kw --service sshd
> 
> *Access granted: True*
> 
>   Matched rules: test_admins
>   Not matched rules: ad_can_login
>   Not matched rules: local_admin_can_login
> [root@freeipa ~]# ipa hbactest --user* j...@kwttestdc.com.kw
> * --host client.kwttestdc.com.kw --service sshd
> 
> *Access granted: True*
> 
>   Matched rules: test_admins
>   Not matched rules: ad_can_login
>   Not matched rules: local_admin_can_login
>
> so my hbac is working partially. How can i fix this.
>
> Regards,
> Ben
>
> On Fri, Apr 29, 2016 at 7:27 PM, Ben .T.George 
> wrote:
>
>> surprisingly i have created some local IPA users and added to same HBAC
>> rule, and removed AD grop ad applied this rule to client, and that got
>> worked.
>>
>> How can i make this AD group with HBAC working?
>>
>> Regards,
>> Ben
>>
>> On Fri, Apr 29, 2016 at 7:12 PM, Ben .T.George 
>> wrote:
>>
>>> HI
>>>
>>> If i disable allow_all  rule,
>>> i cannot able to login to client machine.
>>>
>>> On Fri, Apr 29, 2016 at 7:05 PM, Ben .T.George 
>>> wrote:
>>>
 HI

 actually i have added Domain Admins and the user ben is not part of
 Domain Admins. But when i login to client machine, i am getting below

 -sh-4.2$ id
 uid=1827801104(b...@kwttestdc.com.kw) gid=1827801104(
 b...@kwttestdc.com.kw) groups=1827801104(b...@kwttestdc.com.kw
 ),1827800513(*domain us...@kwttestdc.com.kw 
 *),1827801105(sudo
 adm...@kwttestdc.com.kw)



 On Fri, Apr 29, 2016 at 6:58 PM, Ben .T.George 
 wrote:

> HI
>
> while explaning here it went wrong. actually i did is"
> Added external group to POSIX group"
>
> On Fri, Apr 29, 2016 at 6:56 PM, Jakub Hrozek 
> wrote:
>
>> On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
>> > HI,
>> >
>> > "The other is that the groups might not show up on the client (do
>> they?)"
>>
>> id $user.
>>
>> But I think Alexander noticed the root cause.
>>
>> >
>> > how can i check that.
>> >
>> > Thanks
>> > Ben
>> >
>> > On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek 
>> wrote:
>> >
>> > > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
>> > > > Hi List,
>> > > >
>> > > > I have working setup of one AD, one IPA server and one client
>> server. by
>> > > > default i can login to client server by using AD username.
>> > > >
>> > > > i want to apply HBAC rules against this client server. For that
>> i have
>> > > done
>> > > > below steps.
>> > > >
>> > > > 1. created External group in IPA erver
>> > > > 2. created local POSIX group n IPA server
>> > > > 3. Added AD group to external group
>> > > > 4. added POSIX group to external group.
>> > > >
>> > > > After that  have created HBAC rule by adding both local and
>> external IPA
>> > > > groups, added sshd as service and selected service group as
>> sudo.
>> > > >
>> > > > i have applied this HBAC rule to client server and from web UI
>> and while
>> > > > testing HBAC from web, i am getting access denied .
>> > >
>> > > Sorry, not enough info.
>> > >
>> > > One guess would be that you need to add the "sudo-i" service as
>> well.
>> > > The other is that the groups might not show up on the client (do
>> they?)
>> > >
>> > > Anyway, it might be good idea to follow
>> > > https://fedorahosted.org/sssd/wiki/Troubleshooting
>> > >
>> > > --
>> > > 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
>> > >
>>
>
>

>>>
>>
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

Hi

Adding this this.

in AD i habe added 2 users , ben and jude. In my HBAC rule, i pointed this
specific external group and (were these users)

but while checking the rule from IPA server using hbactest, both users test
passes and showing one rol. but in actual only ben can able to login to
client machine , while jude cannot.

[root@freeipa ~]# ipa hbactest --user *b...@kwttestdc.com.kw
* --host client.kwttestdc.com.kw --service sshd

*Access granted: True*

  Matched rules: test_admins
  Not matched rules: ad_can_login
  Not matched rules: local_admin_can_login
[root@freeipa ~]# ipa hbactest --user* j...@kwttestdc.com.kw
* --host client.kwttestdc.com.kw --service sshd

*Access granted: True*

  Matched rules: test_admins
  Not matched rules: ad_can_login
  Not matched rules: local_admin_can_login

so my hbac is working partially. How can i fix this.

Regards,
Ben

On Fri, Apr 29, 2016 at 7:27 PM, Ben .T.George 
wrote:

> surprisingly i have created some local IPA users and added to same HBAC
> rule, and removed AD grop ad applied this rule to client, and that got
> worked.
>
> How can i make this AD group with HBAC working?
>
> Regards,
> Ben
>
> On Fri, Apr 29, 2016 at 7:12 PM, Ben .T.George 
> wrote:
>
>> HI
>>
>> If i disable allow_all  rule,
>> i cannot able to login to client machine.
>>
>> On Fri, Apr 29, 2016 at 7:05 PM, Ben .T.George 
>> wrote:
>>
>>> HI
>>>
>>> actually i have added Domain Admins and the user ben is not part of
>>> Domain Admins. But when i login to client machine, i am getting below
>>>
>>> -sh-4.2$ id
>>> uid=1827801104(b...@kwttestdc.com.kw) gid=1827801104(b...@kwttestdc.com.kw)
>>> groups=1827801104(b...@kwttestdc.com.kw),1827800513(*domain
>>> us...@kwttestdc.com.kw *),1827801105(sudo
>>> adm...@kwttestdc.com.kw)
>>>
>>>
>>>
>>> On Fri, Apr 29, 2016 at 6:58 PM, Ben .T.George 
>>> wrote:
>>>
 HI

 while explaning here it went wrong. actually i did is"
 Added external group to POSIX group"

 On Fri, Apr 29, 2016 at 6:56 PM, Jakub Hrozek 
 wrote:

> On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
> > HI,
> >
> > "The other is that the groups might not show up on the client (do
> they?)"
>
> id $user.
>
> But I think Alexander noticed the root cause.
>
> >
> > how can i check that.
> >
> > Thanks
> > Ben
> >
> > On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek 
> wrote:
> >
> > > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
> > > > Hi List,
> > > >
> > > > I have working setup of one AD, one IPA server and one client
> server. by
> > > > default i can login to client server by using AD username.
> > > >
> > > > i want to apply HBAC rules against this client server. For that
> i have
> > > done
> > > > below steps.
> > > >
> > > > 1. created External group in IPA erver
> > > > 2. created local POSIX group n IPA server
> > > > 3. Added AD group to external group
> > > > 4. added POSIX group to external group.
> > > >
> > > > After that  have created HBAC rule by adding both local and
> external IPA
> > > > groups, added sshd as service and selected service group as sudo.
> > > >
> > > > i have applied this HBAC rule to client server and from web UI
> and while
> > > > testing HBAC from web, i am getting access denied .
> > >
> > > Sorry, not enough info.
> > >
> > > One guess would be that you need to add the "sudo-i" service as
> well.
> > > The other is that the groups might not show up on the client (do
> they?)
> > >
> > > Anyway, it might be good idea to follow
> > > https://fedorahosted.org/sssd/wiki/Troubleshooting
> > >
> > > --
> > > 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
> > >
>


>>>
>>
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

surprisingly i have created some local IPA users and added to same HBAC
rule, and removed AD grop ad applied this rule to client, and that got
worked.

How can i make this AD group with HBAC working?

Regards,
Ben

On Fri, Apr 29, 2016 at 7:12 PM, Ben .T.George 
wrote:

> HI
>
> If i disable allow_all  rule,
> i cannot able to login to client machine.
>
> On Fri, Apr 29, 2016 at 7:05 PM, Ben .T.George 
> wrote:
>
>> HI
>>
>> actually i have added Domain Admins and the user ben is not part of
>> Domain Admins. But when i login to client machine, i am getting below
>>
>> -sh-4.2$ id
>> uid=1827801104(b...@kwttestdc.com.kw) gid=1827801104(b...@kwttestdc.com.kw)
>> groups=1827801104(b...@kwttestdc.com.kw),1827800513(*domain
>> us...@kwttestdc.com.kw *),1827801105(sudo
>> adm...@kwttestdc.com.kw)
>>
>>
>>
>> On Fri, Apr 29, 2016 at 6:58 PM, Ben .T.George 
>> wrote:
>>
>>> HI
>>>
>>> while explaning here it went wrong. actually i did is"
>>> Added external group to POSIX group"
>>>
>>> On Fri, Apr 29, 2016 at 6:56 PM, Jakub Hrozek 
>>> wrote:
>>>
 On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
 > HI,
 >
 > "The other is that the groups might not show up on the client (do
 they?)"

 id $user.

 But I think Alexander noticed the root cause.

 >
 > how can i check that.
 >
 > Thanks
 > Ben
 >
 > On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek 
 wrote:
 >
 > > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
 > > > Hi List,
 > > >
 > > > I have working setup of one AD, one IPA server and one client
 server. by
 > > > default i can login to client server by using AD username.
 > > >
 > > > i want to apply HBAC rules against this client server. For that i
 have
 > > done
 > > > below steps.
 > > >
 > > > 1. created External group in IPA erver
 > > > 2. created local POSIX group n IPA server
 > > > 3. Added AD group to external group
 > > > 4. added POSIX group to external group.
 > > >
 > > > After that  have created HBAC rule by adding both local and
 external IPA
 > > > groups, added sshd as service and selected service group as sudo.
 > > >
 > > > i have applied this HBAC rule to client server and from web UI
 and while
 > > > testing HBAC from web, i am getting access denied .
 > >
 > > Sorry, not enough info.
 > >
 > > One guess would be that you need to add the "sudo-i" service as
 well.
 > > The other is that the groups might not show up on the client (do
 they?)
 > >
 > > Anyway, it might be good idea to follow
 > > https://fedorahosted.org/sssd/wiki/Troubleshooting
 > >
 > > --
 > > 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
 > >

>>>
>>>
>>
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

HI

If i disable allow_all  rule,
i cannot able to login to client machine.

On Fri, Apr 29, 2016 at 7:05 PM, Ben .T.George 
wrote:

> HI
>
> actually i have added Domain Admins and the user ben is not part of Domain
> Admins. But when i login to client machine, i am getting below
>
> -sh-4.2$ id
> uid=1827801104(b...@kwttestdc.com.kw) gid=1827801104(b...@kwttestdc.com.kw)
> groups=1827801104(b...@kwttestdc.com.kw),1827800513(*domain
> us...@kwttestdc.com.kw *),1827801105(sudo
> adm...@kwttestdc.com.kw)
>
>
>
> On Fri, Apr 29, 2016 at 6:58 PM, Ben .T.George 
> wrote:
>
>> HI
>>
>> while explaning here it went wrong. actually i did is"
>> Added external group to POSIX group"
>>
>> On Fri, Apr 29, 2016 at 6:56 PM, Jakub Hrozek  wrote:
>>
>>> On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
>>> > HI,
>>> >
>>> > "The other is that the groups might not show up on the client (do
>>> they?)"
>>>
>>> id $user.
>>>
>>> But I think Alexander noticed the root cause.
>>>
>>> >
>>> > how can i check that.
>>> >
>>> > Thanks
>>> > Ben
>>> >
>>> > On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek 
>>> wrote:
>>> >
>>> > > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
>>> > > > Hi List,
>>> > > >
>>> > > > I have working setup of one AD, one IPA server and one client
>>> server. by
>>> > > > default i can login to client server by using AD username.
>>> > > >
>>> > > > i want to apply HBAC rules against this client server. For that i
>>> have
>>> > > done
>>> > > > below steps.
>>> > > >
>>> > > > 1. created External group in IPA erver
>>> > > > 2. created local POSIX group n IPA server
>>> > > > 3. Added AD group to external group
>>> > > > 4. added POSIX group to external group.
>>> > > >
>>> > > > After that  have created HBAC rule by adding both local and
>>> external IPA
>>> > > > groups, added sshd as service and selected service group as sudo.
>>> > > >
>>> > > > i have applied this HBAC rule to client server and from web UI and
>>> while
>>> > > > testing HBAC from web, i am getting access denied .
>>> > >
>>> > > Sorry, not enough info.
>>> > >
>>> > > One guess would be that you need to add the "sudo-i" service as well.
>>> > > The other is that the groups might not show up on the client (do
>>> they?)
>>> > >
>>> > > Anyway, it might be good idea to follow
>>> > > https://fedorahosted.org/sssd/wiki/Troubleshooting
>>> > >
>>> > > --
>>> > > 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
>>> > >
>>>
>>
>>
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

HI

actually i have added Domain Admins and the user ben is not part of Domain
Admins. But when i login to client machine, i am getting below

-sh-4.2$ id
uid=1827801104(b...@kwttestdc.com.kw) gid=1827801104(b...@kwttestdc.com.kw)
groups=1827801104(b...@kwttestdc.com.kw),1827800513(*domain
us...@kwttestdc.com.kw *),1827801105(sudo
adm...@kwttestdc.com.kw)



On Fri, Apr 29, 2016 at 6:58 PM, Ben .T.George 
wrote:

> HI
>
> while explaning here it went wrong. actually i did is"
> Added external group to POSIX group"
>
> On Fri, Apr 29, 2016 at 6:56 PM, Jakub Hrozek  wrote:
>
>> On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
>> > HI,
>> >
>> > "The other is that the groups might not show up on the client (do
>> they?)"
>>
>> id $user.
>>
>> But I think Alexander noticed the root cause.
>>
>> >
>> > how can i check that.
>> >
>> > Thanks
>> > Ben
>> >
>> > On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek 
>> wrote:
>> >
>> > > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
>> > > > Hi List,
>> > > >
>> > > > I have working setup of one AD, one IPA server and one client
>> server. by
>> > > > default i can login to client server by using AD username.
>> > > >
>> > > > i want to apply HBAC rules against this client server. For that i
>> have
>> > > done
>> > > > below steps.
>> > > >
>> > > > 1. created External group in IPA erver
>> > > > 2. created local POSIX group n IPA server
>> > > > 3. Added AD group to external group
>> > > > 4. added POSIX group to external group.
>> > > >
>> > > > After that  have created HBAC rule by adding both local and
>> external IPA
>> > > > groups, added sshd as service and selected service group as sudo.
>> > > >
>> > > > i have applied this HBAC rule to client server and from web UI and
>> while
>> > > > testing HBAC from web, i am getting access denied .
>> > >
>> > > Sorry, not enough info.
>> > >
>> > > One guess would be that you need to add the "sudo-i" service as well.
>> > > The other is that the groups might not show up on the client (do
>> they?)
>> > >
>> > > Anyway, it might be good idea to follow
>> > > https://fedorahosted.org/sssd/wiki/Troubleshooting
>> > >
>> > > --
>> > > 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
>> > >
>>
>
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

HI

while explaning here it went wrong. actually i did is"
Added external group to POSIX group"

On Fri, Apr 29, 2016 at 6:56 PM, Jakub Hrozek  wrote:

> On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
> > HI,
> >
> > "The other is that the groups might not show up on the client (do they?)"
>
> id $user.
>
> But I think Alexander noticed the root cause.
>
> >
> > how can i check that.
> >
> > Thanks
> > Ben
> >
> > On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek 
> wrote:
> >
> > > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
> > > > Hi List,
> > > >
> > > > I have working setup of one AD, one IPA server and one client
> server. by
> > > > default i can login to client server by using AD username.
> > > >
> > > > i want to apply HBAC rules against this client server. For that i
> have
> > > done
> > > > below steps.
> > > >
> > > > 1. created External group in IPA erver
> > > > 2. created local POSIX group n IPA server
> > > > 3. Added AD group to external group
> > > > 4. added POSIX group to external group.
> > > >
> > > > After that  have created HBAC rule by adding both local and external
> IPA
> > > > groups, added sshd as service and selected service group as sudo.
> > > >
> > > > i have applied this HBAC rule to client server and from web UI and
> while
> > > > testing HBAC from web, i am getting access denied .
> > >
> > > Sorry, not enough info.
> > >
> > > One guess would be that you need to add the "sudo-i" service as well.
> > > The other is that the groups might not show up on the client (do they?)
> > >
> > > Anyway, it might be good idea to follow
> > > https://fedorahosted.org/sssd/wiki/Troubleshooting
> > >
> > > --
> > > 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
> > >
>
-- 
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] HBAC with Active directory group is not working

[Jakub Hrozek]

On Fri, Apr 29, 2016 at 06:32:28PM +0300, Ben .T.George wrote:
> HI,
> 
> "The other is that the groups might not show up on the client (do they?)"

id $user.

But I think Alexander noticed the root cause.

> 
> how can i check that.
> 
> Thanks
> Ben
> 
> On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek  wrote:
> 
> > On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
> > > Hi List,
> > >
> > > I have working setup of one AD, one IPA server and one client server. by
> > > default i can login to client server by using AD username.
> > >
> > > i want to apply HBAC rules against this client server. For that i have
> > done
> > > below steps.
> > >
> > > 1. created External group in IPA erver
> > > 2. created local POSIX group n IPA server
> > > 3. Added AD group to external group
> > > 4. added POSIX group to external group.
> > >
> > > After that  have created HBAC rule by adding both local and external IPA
> > > groups, added sshd as service and selected service group as sudo.
> > >
> > > i have applied this HBAC rule to client server and from web UI and while
> > > testing HBAC from web, i am getting access denied .
> >
> > Sorry, not enough info.
> >
> > One guess would be that you need to add the "sudo-i" service as well.
> > The other is that the groups might not show up on the client (do they?)
> >
> > Anyway, it might be good idea to follow
> > https://fedorahosted.org/sssd/wiki/Troubleshooting
> >
> > --
> > 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
> >

-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

Hi

I have created 2 fresh users now and i was running below,

[root@freeipa log]# ipa hbactest --user "KWTTESTDC\jude" --host `hostname`
--service sshd
ipa: ERROR: trusted domain user not found
[root@freeipa log]# ipa hbactest --user "KWTTESTDC\muneer" --host
`hostname` --service sshd
ipa: ERROR: trusted domain user not found

but i can able to test with old users,

[root@freeipa log]# ipa hbactest --user "KWTTESTDC\Administrator" --host
`hostname` --service sshd

Access granted: True

  Matched rules: allow_all
  Not matched rules: ad_can_login
  Not matched rules: local_admin_can_login
[root@freeipa log]# ipa hbactest --user "KWTTESTDC\ben" --host `hostname`
--service sshd

Access granted: True

  Matched rules: ad_can_login
  Matched rules: allow_all
  Not matched rules: local_admin_can_login


Is there any sync time for trust.?

when i was trying ipa trust-fetch-domains, i am getting below

[root@freeipa log]# ipa trust-fetch-domains "kwttestdc.com.kw"
ipa: ERROR: error on server 'freeipa.idm.local': Fetching domains from
trusted forest failed. See details in the error_log

Thanks & Regards,
Ben

On Fri, Apr 29, 2016 at 6:33 PM, Ben .T.George 
wrote:

> Hi Alex,
>
> yea my mistake.
>
> i was following u this
>
>
> http://www.freeipa.org/page/Active_Directory_trust_setup#Allow_access_for_users_from_AD_domain_to_protected_resources
>
>
>
> On Fri, Apr 29, 2016 at 6:03 PM, Alexander Bokovoy 
> wrote:
>
>> On Fri, 29 Apr 2016, Ben .T.George wrote:
>>
>>> Hi List,
>>>
>>> I have working setup of one AD, one IPA server and one client server. by
>>> default i can login to client server by using AD username.
>>>
>>> i want to apply HBAC rules against this client server. For that i have
>>> done
>>> below steps.
>>>
>>> 1. created External group in IPA erver
>>> 2. created local POSIX group n IPA server
>>> 3. Added AD group to external group
>>> 4. added POSIX group to external group.
>>>
>> You should have added external group to POSIX group, not the other way
>> around.
>>
>> --
>> / Alexander Bokovoy
>>
>
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

Hi Alex,

yea my mistake.

i was following u this

http://www.freeipa.org/page/Active_Directory_trust_setup#Allow_access_for_users_from_AD_domain_to_protected_resources



On Fri, Apr 29, 2016 at 6:03 PM, Alexander Bokovoy 
wrote:

> On Fri, 29 Apr 2016, Ben .T.George wrote:
>
>> Hi List,
>>
>> I have working setup of one AD, one IPA server and one client server. by
>> default i can login to client server by using AD username.
>>
>> i want to apply HBAC rules against this client server. For that i have
>> done
>> below steps.
>>
>> 1. created External group in IPA erver
>> 2. created local POSIX group n IPA server
>> 3. Added AD group to external group
>> 4. added POSIX group to external group.
>>
> You should have added external group to POSIX group, not the other way
> around.
>
> --
> / Alexander Bokovoy
>
-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

HI,

"The other is that the groups might not show up on the client (do they?)"

how can i check that.

Thanks
Ben

On Fri, Apr 29, 2016 at 5:59 PM, Jakub Hrozek  wrote:

> On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
> > Hi List,
> >
> > I have working setup of one AD, one IPA server and one client server. by
> > default i can login to client server by using AD username.
> >
> > i want to apply HBAC rules against this client server. For that i have
> done
> > below steps.
> >
> > 1. created External group in IPA erver
> > 2. created local POSIX group n IPA server
> > 3. Added AD group to external group
> > 4. added POSIX group to external group.
> >
> > After that  have created HBAC rule by adding both local and external IPA
> > groups, added sshd as service and selected service group as sudo.
> >
> > i have applied this HBAC rule to client server and from web UI and while
> > testing HBAC from web, i am getting access denied .
>
> Sorry, not enough info.
>
> One guess would be that you need to add the "sudo-i" service as well.
> The other is that the groups might not show up on the client (do they?)
>
> Anyway, it might be good idea to follow
> https://fedorahosted.org/sssd/wiki/Troubleshooting
>
> --
> 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
>
-- 
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] HBAC with Active directory group is not working

[Alexander Bokovoy]

On Fri, 29 Apr 2016, Ben .T.George wrote:

Hi List,

I have working setup of one AD, one IPA server and one client server. by
default i can login to client server by using AD username.

i want to apply HBAC rules against this client server. For that i have done
below steps.

1. created External group in IPA erver
2. created local POSIX group n IPA server
3. Added AD group to external group
4. added POSIX group to external group.

You should have added external group to POSIX group, not the other way
around.

--
/ Alexander Bokovoy

--
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] HBAC with Active directory group is not working

[Jakub Hrozek]

On Fri, Apr 29, 2016 at 05:38:30PM +0300, Ben .T.George wrote:
> Hi List,
> 
> I have working setup of one AD, one IPA server and one client server. by
> default i can login to client server by using AD username.
> 
> i want to apply HBAC rules against this client server. For that i have done
> below steps.
> 
> 1. created External group in IPA erver
> 2. created local POSIX group n IPA server
> 3. Added AD group to external group
> 4. added POSIX group to external group.
> 
> After that  have created HBAC rule by adding both local and external IPA
> groups, added sshd as service and selected service group as sudo.
> 
> i have applied this HBAC rule to client server and from web UI and while
> testing HBAC from web, i am getting access denied .

Sorry, not enough info.

One guess would be that you need to add the "sudo-i" service as well.
The other is that the groups might not show up on the client (do they?)

Anyway, it might be good idea to follow
https://fedorahosted.org/sssd/wiki/Troubleshooting

-- 
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] HBAC with Active directory group is not working

[Ben .T.George]

Hi List,

I have working setup of one AD, one IPA server and one client server. by
default i can login to client server by using AD username.

i want to apply HBAC rules against this client server. For that i have done
below steps.

1. created External group in IPA erver
2. created local POSIX group n IPA server
3. Added AD group to external group
4. added POSIX group to external group.

After that  have created HBAC rule by adding both local and external IPA
groups, added sshd as service and selected service group as sudo.

i have applied this HBAC rule to client server and from web UI and while
testing HBAC from web, i am getting access denied .

How can i implement HBAC with Active directory user group.

Regards,
Ben
-- 
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] HBAC implementation help

[Martin Basti]

On 29.04.2016 13:27, Ben .T.George wrote:

HI

Thanks for your reply.

can i do this external group mapping from web UI?


You can create External Group using webUI (user groups/ add group/ 
choose external radio button)


More doc about HBAC: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html


Martin


On Fri, Apr 29, 2016 at 10:50 AM, Jakub Hrozek > wrote:


On Fri, Apr 29, 2016 at 12:03:42AM +0300, Ben .T.George wrote:
> Hi List,
>
> i have a working setup of IPA with AD integrated and one client
joined.
>
> i want to implement HBAC rules against this client. can anyone
please share
> me good articles of implementing HBAC from web UI.

I'm not sure about the web UI, but as a general rule you'll want
to add
an external group (created with --external) as a member of a POSIX
group
and reference the POSIX group in the HBAC rule. The AD members
should be
added as members of the external group.

--
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






-- 
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] HBAC implementation help

[Ben .T.George]

HI

Thanks for your reply.

can i do this external group mapping from web UI?

On Fri, Apr 29, 2016 at 10:50 AM, Jakub Hrozek  wrote:

> On Fri, Apr 29, 2016 at 12:03:42AM +0300, Ben .T.George wrote:
> > Hi List,
> >
> > i have a working setup of IPA with AD integrated and one client joined.
> >
> > i want to implement HBAC rules against this client. can anyone please
> share
> > me good articles of implementing HBAC from web UI.
>
> I'm not sure about the web UI, but as a general rule you'll want to add
> an external group (created with --external) as a member of a POSIX group
> and reference the POSIX group in the HBAC rule. The AD members should be
> added as members of the external group.
>
> --
> 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
>
-- 
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] HBAC implementation help

[Jakub Hrozek]

On Fri, Apr 29, 2016 at 12:03:42AM +0300, Ben .T.George wrote:
> Hi List,
> 
> i have a working setup of IPA with AD integrated and one client joined.
> 
> i want to implement HBAC rules against this client. can anyone please share
> me good articles of implementing HBAC from web UI.

I'm not sure about the web UI, but as a general rule you'll want to add
an external group (created with --external) as a member of a POSIX group
and reference the POSIX group in the HBAC rule. The AD members should be
added as members of the external group.

-- 
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] HBAC implementation help

[Ben .T.George]

Hi List,

i have a working setup of IPA with AD integrated and one client joined.

i want to implement HBAC rules against this client. can anyone please share
me good articles of implementing HBAC from web UI.


Thanks & Regards,
Ben
-- 
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Tue, Dec 08, 2015 at 04:10:42PM -0600, Sauls, Jeff wrote:
> > Jakub Hrozek wrote:
> > 
> > On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote:
> > > > Jakub Hrozek wrote:
> > > >
> > > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote:
> > > > > Hello,
> > > > >
> > > > > We are having a problem with HBAC that appears to be related to
> > > > > group membership lookup.  I am testing with a new install on RHEL
> > > > > 7.2 with a cross-forest trust with AD.  When an AD user attempts
> > > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element"
> > > > > can report a different number of groups each time and never seems to
> > contain the full list.
> > > > > For the testing account, running the 'id' command returns 153 groups.
> > > > > The ipa group "ad_admin" has setup to be able to log in anywhere,
> > > > > everyone else is denied.  With the default allow_all rule enabled,
> > > > > everything works as expected.  Any ideas on where I can look next?
> > > >
> > > > I assume the group membership is OK on the server, but not the
> > > > client? Can you enable debugging and also include the full logs from
> > > > the client after doing sss_cache -E on the client?
> > >
> > > I've done some more testing and installed a RHEL 6.6 client, the issue 
> > > doesn't
> > occur there since it is not pulling in AD groups, it only shows the single 
> > POSIX
> > group.  The server is running 7.2 and I get the same issue logging into it.
> > 
> > To make sure I understand -- the group you expect to be returned on the 
> > server
> > is not either? So there is a consistent failure on the server as well?
> > 
> > (It's important to see where the failure is, the server and the client use
> > different methods to obtain the group memberships. The server talks 
> > directly to
> > the AD, the clients talk to the server)
> > 
> > >
> > > This is the log section for a login that failed due to "Access denied
> > > by HBAC rules"  http://pastebin.com/paiBjG96 It shows it failing with 112
> > groups, but I've had it pass at 113 and fail on another user at 66.
> > >
> > >
> 
> The server and client show the same symptoms. 

Ah, OK, then it sounds different from the other cases we've seen recently
and we need to fix the server first, because the clients read data from
the server.

If you can catch the failure with logs that update the cache (so sss_cache
-E was run before the id attempt), please go ahead and file a bug against
sssd. It would also be nice to list what groups are not displayed but
should be (or which work intermittently) and describe the hierarchy if
possible, at least the part that includes the faulty groups, so we can
set a similar environment locally.

> If I clear the cache on both and log into each, the number of groups can 
> change between cache clearings.  The only group used in the HBAC rule 
> "admin-access" is a POSIX group "ad_admins".  Ad_admins contains an external 
> group with the AD user account in it.  I can't consistently repeat it nor 
> find a pattern to the failure.
> 
> After many cache clears and reboots testing with the server, I've managed to 
> get it into a failure state.  After the reboot, I successfully logged in with 
> the AD account.  It showed [113] groups in the log.  I logged out and logged 
> back in with the same account a few minutes later and was denied by HABC 
> rules, the group count shows [71] for this session.  Logging in 30 minutes 
> later still fails, but show [112] groups now.  On the client system, I 
> cleared the cache and rebooted it, I'm able to log into it with the AD 
> account and it shows [72] groups in the log.
> 
> -Jeff
> 
> 
> -- 
> 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

-- 
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] HBAC access denied, all AD groups not detected

[Sauls, Jeff]

> Jakub Hrozek wrote:
> 
> On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote:
> > > Jakub Hrozek wrote:
> > >
> > > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote:
> > > > Hello,
> > > >
> > > > We are having a problem with HBAC that appears to be related to
> > > > group membership lookup.  I am testing with a new install on RHEL
> > > > 7.2 with a cross-forest trust with AD.  When an AD user attempts
> > > > to log into a client (RH 6.7 or 7.2) the "hbac_eval_user_element"
> > > > can report a different number of groups each time and never seems to
> contain the full list.
> > > > For the testing account, running the 'id' command returns 153 groups.
> > > > The ipa group "ad_admin" has setup to be able to log in anywhere,
> > > > everyone else is denied.  With the default allow_all rule enabled,
> > > > everything works as expected.  Any ideas on where I can look next?
> > >
> > > I assume the group membership is OK on the server, but not the
> > > client? Can you enable debugging and also include the full logs from
> > > the client after doing sss_cache -E on the client?
> >
> > I've done some more testing and installed a RHEL 6.6 client, the issue 
> > doesn't
> occur there since it is not pulling in AD groups, it only shows the single 
> POSIX
> group.  The server is running 7.2 and I get the same issue logging into it.
> 
> To make sure I understand -- the group you expect to be returned on the server
> is not either? So there is a consistent failure on the server as well?
> 
> (It's important to see where the failure is, the server and the client use
> different methods to obtain the group memberships. The server talks directly 
> to
> the AD, the clients talk to the server)
> 
> >
> > This is the log section for a login that failed due to "Access denied
> > by HBAC rules"  http://pastebin.com/paiBjG96 It shows it failing with 112
> groups, but I've had it pass at 113 and fail on another user at 66.
> >
> >

The server and client show the same symptoms.  If I clear the cache on both and 
log into each, the number of groups can change between cache clearings.  The 
only group used in the HBAC rule "admin-access" is a POSIX group "ad_admins".  
Ad_admins contains an external group with the AD user account in it.  I can't 
consistently repeat it nor find a pattern to the failure.

After many cache clears and reboots testing with the server, I've managed to 
get it into a failure state.  After the reboot, I successfully logged in with 
the AD account.  It showed [113] groups in the log.  I logged out and logged 
back in with the same account a few minutes later and was denied by HABC rules, 
the group count shows [71] for this session.  Logging in 30 minutes later still 
fails, but show [112] groups now.  On the client system, I cleared the cache 
and rebooted it, I'm able to log into it with the AD account and it shows [72] 
groups in the log.

-Jeff


-- 
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Mon, Dec 07, 2015 at 02:04:26PM -0600, Sauls, Jeff wrote:
> > Jakub Hrozek wrote:
> > 
> > On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote:
> > > Hello,
> > >
> > > We are having a problem with HBAC that appears to be related to group
> > > membership lookup.  I am testing with a new install on RHEL 7.2 with a
> > > cross-forest trust with AD.  When an AD user attempts to log into a
> > > client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a
> > > different number of groups each time and never seems to contain the full 
> > > list.
> > > For the testing account, running the 'id' command returns 153 groups.
> > > The ipa group "ad_admin" has setup to be able to log in anywhere,
> > > everyone else is denied.  With the default allow_all rule enabled,
> > > everything works as expected.  Any ideas on where I can look next?
> > 
> > I assume the group membership is OK on the server, but not the client? Can 
> > you
> > enable debugging and also include the full logs from the client after doing
> > sss_cache -E on the client?
> 
> I've done some more testing and installed a RHEL 6.6 client, the issue 
> doesn't occur there since it is not pulling in AD groups, it only shows the 
> single POSIX group.  The server is running 7.2 and I get the same issue 
> logging into it.

To make sure I understand -- the group you expect to be returned on the
server is not either? So there is a consistent failure on the server as
well?

(It's important to see where the failure is, the server and the client
use different methods to obtain the group memberships. The server talks
directly to the AD, the clients talk to the server)

> 
> This is the log section for a login that failed due to "Access denied by HBAC 
> rules"  http://pastebin.com/paiBjG96
> It shows it failing with 112 groups, but I've had it pass at 113 and fail on 
> another user at 66.
> 
> 
> -- 
> 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

-- 
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] HBAC access denied, all AD groups not detected

[Sauls, Jeff]

> Jakub Hrozek wrote:
> 
> On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote:
> > Hello,
> >
> > We are having a problem with HBAC that appears to be related to group
> > membership lookup.  I am testing with a new install on RHEL 7.2 with a
> > cross-forest trust with AD.  When an AD user attempts to log into a
> > client (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a
> > different number of groups each time and never seems to contain the full 
> > list.
> > For the testing account, running the 'id' command returns 153 groups.
> > The ipa group "ad_admin" has setup to be able to log in anywhere,
> > everyone else is denied.  With the default allow_all rule enabled,
> > everything works as expected.  Any ideas on where I can look next?
> 
> I assume the group membership is OK on the server, but not the client? Can you
> enable debugging and also include the full logs from the client after doing
> sss_cache -E on the client?

I've done some more testing and installed a RHEL 6.6 client, the issue doesn't 
occur there since it is not pulling in AD groups, it only shows the single 
POSIX group.  The server is running 7.2 and I get the same issue logging into 
it.

This is the log section for a login that failed due to "Access denied by HBAC 
rules"  http://pastebin.com/paiBjG96
It shows it failing with 112 groups, but I've had it pass at 113 and fail on 
another user at 66.


-- 
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] HBAC access denied, all AD groups not detected

[Jakub Hrozek]

On Fri, Dec 04, 2015 at 02:03:04PM -0600, Sauls, Jeff wrote:
> Hello,
> 
> We are having a problem with HBAC that appears to be related to group
> membership lookup.  I am testing with a new install on RHEL 7.2 with a
> cross-forest trust with AD.  When an AD user attempts to log into a client
> (RH 6.7 or 7.2) the "hbac_eval_user_element" can report a different
> number of groups each time and never seems to contain the full list.
> For the testing account, running the 'id' command returns 153 groups.
> The ipa group "ad_admin" has setup to be able to log in anywhere, everyone
> else is denied.  With the default allow_all rule enabled, everything works
> as expected.  Any ideas on where I can look next?

I assume the group membership is OK on the server, but not the client? Can
you enable debugging and also include the full logs from the client after
doing sss_cache -E on the client?

-- 
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] HBAC access denied, all AD groups not detected

[Sauls, Jeff]

Hello,

We are having a problem with HBAC that appears to be related to group 
membership lookup.  I am testing with a new install on RHEL 7.2 with a 
cross-forest trust with AD.  When an AD user attempts to log into a client (RH 
6.7 or 7.2) the "hbac_eval_user_element" can report a different number of 
groups each time and never seems to contain the full list.  For the testing 
account, running the 'id' command returns 153 groups.  The ipa group "ad_admin" 
has setup to be able to log in anywhere, everyone else is denied.  With the 
default allow_all rule enabled, everything works as expected.  Any ideas on 
where I can look next?

Example grep from the client domain log (account had no changes to group 
membership):
(Fri Dec  4 00:46:35 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [113] groups for [testu...@ad.domain.com]
(Fri Dec  4 00:47:31 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [112] groups for [testu...@ad.domain.com]
(Fri Dec  4 01:00:20 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [72] groups for [testu...@ad.domain.com]
(Fri Dec  4 01:10:24 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [72] groups for [testu...@ad.domain.com]
(Fri Dec  4 01:14:20 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [72] groups for [testu...@ad.domain.com]
(Fri Dec  4 01:24:21 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [72] groups for [testu...@ad.domain.com]
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): [73] groups for [testu...@ad.domain.com]

Example of an HBAC rule passing:
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x2000): Skipping non-group memberOf [CN=]
... repeated for however many groups happened to be examined
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x1000): Added group [ad_admins] for user [testu...@ad.domain.com]
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x2469f40
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x2460080
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running 
timer event 0x2469f40 "ltdb_callback"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): 
Destroying timer event 0x2460080 "ltdb_timeout"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending 
timer event 0x2469f40 "ltdb_callback"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x245aee0
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x2460080
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running 
timer event 0x245aee0 "ltdb_callback"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): 
Destroying timer event 0x2460080 "ltdb_timeout"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending 
timer event 0x245aee0 "ltdb_callback"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x2469f40
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x2460080
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running 
timer event 0x2469f40 "ltdb_callback"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): 
Destroying timer event 0x2460080 "ltdb_timeout"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending 
timer event 0x2469f40 "ltdb_callback"
(Fri Dec  4 14:27:57 2015) [sssd[be[ipa.domain.com]]] [ipa_hbac_evaluate_rules] 
(0x0080): Access granted by HBAC rule [admin-access]


Example of an HBAC rule failing:
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x2000): Skipping non-group memberOf [CN=]
... repeated for however many groups happened to be examined
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [hbac_eval_user_element] 
(0x2000): Skipping non-group memberOf [CN=]
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x26f8d00
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_timeout": 0x26e18d0
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Running 
timer event 0x26f8d00 "ltdb_callback"
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): 
Destroying timer event 0x26e18d0 "ltdb_timeout"
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Ending 
timer event 0x26f8d00 "ltdb_callback"
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb] (0x4000): Added 
timed event "ltdb_callback": 0x27e51f0
(Thu Dec  3 22:30:10 2015) [sssd[be[ipa.domain.com]]] [ldb

Re: [Freeipa-users] HBAC - Limit SSH access to "test" systems

[Alexander Bokovoy]

On Mon, 30 Nov 2015, Alexander Skwar wrote:

Hello Alexander ;)

2015-11-30 10:38 GMT+01:00 Alexander Bokovoy :


HBAC is enforced by SSSD over PAM. All you need to ensure is that an
application (sshd in this case) uses PAM. Then you setup HBAC rules,
disable allow_all rule, and then SSSD will verify rules on logon via
sshd, checking all rules for service 'sshd' and applying to this host
(via hostgroup or to all hosts).


Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also
change the "default" behaviour? I mean, by default, everything will
be allowed for everyone on every system.

When I deactivate the allow_all - won't that mean, that nothing will
be allowed for everyone on all systems?

Yes. HBAC system is built around a simple principle: everything is
denied unless allowed explicitly with specific rules.

We supply 'allow_all' rule for defaults and it is your duty to create
HBAC rules which suit your deployment needs.


Playing with the HBAC Test thingie in the web interface seems to imply
that. And because of that, I now have 3 rules:

1) allow_all_but_ssh
2) ssh_prod
3) ssh_test

1) Who: Anyone, Accessing: Any host, Via Service: Selected every
  service, but not sshd
2) Who: User groups: ops, Accessing: Host groups: prod, Via service: sshd
3) Who: Anyone, Accessing: Host groups: test, Via service: sshd

That's somewhat fine, but I dislike the "allow_all_but_ssh" rule there.
Reason: I manually have to select every service and remove sshd. But if
a new service were to be added, I'd have to remember to add it there as
well. Not cool. Even more so, because I'm not the only admin. Colleagues
would have to know this as well. Not cool².

Somehow I'm missing "deny"-rules, I think. Nice to have allow rules,
but I'm rather looking for a way to deny something :/

Don't know, but that seems to be too complicated. Or is that really the
way to do that?

Deny rules complicate things a lot, really. You can create a service
group that includes all your services but sshd and assign that service
group to allow rule. Maintaining a service group is less problematic
than looking into what rules deny/allow. Consider also the contextual
problem of what to do if HBAC rules become unavailable -- should the
unavailability of deny rule be treated as allow or not? We chose to
define deny by default and add allow rules on top of it.

All this is covered in IPA documentation.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/configuring-host-access.html

--
/ Alexander Bokovoy

--
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] HBAC - Limit SSH access to "test" systems

[Jan Pazdziora]

On Mon, Nov 30, 2015 at 11:18:15AM +0100, Alexander Skwar wrote:
> 
> Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also
> change the "default" behaviour? I mean, by default, everything will
> be allowed for everyone on every system.

No.

> When I deactivate the allow_all - won't that mean, that nothing will
> be allowed for everyone on all systems?

That's right, nothing will be allowed.

Disabling allow_all has the potential of making everything stop
working. You need to plan carefully and replace the allow_all with
tailored rules. For example, see

http://www.freeipa.org/page/Howto/HBAC_and_allow_all

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat

-- 
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] HBAC - Limit SSH access to "test" systems

[Alexander Skwar]

Hello Alexander ;)

2015-11-30 10:38 GMT+01:00 Alexander Bokovoy :

> HBAC is enforced by SSSD over PAM. All you need to ensure is that an
> application (sshd in this case) uses PAM. Then you setup HBAC rules,
> disable allow_all rule, and then SSSD will verify rules on logon via
> sshd, checking all rules for service 'sshd' and applying to this host
> (via hostgroup or to all hosts).

Hm, okay. But when I deactivate the "allow_all" rule, doesn't that also
change the "default" behaviour? I mean, by default, everything will
be allowed for everyone on every system.

When I deactivate the allow_all - won't that mean, that nothing will
be allowed for everyone on all systems?

Playing with the HBAC Test thingie in the web interface seems to imply
that. And because of that, I now have 3 rules:

1) allow_all_but_ssh
2) ssh_prod
3) ssh_test

1) Who: Anyone, Accessing: Any host, Via Service: Selected every
   service, but not sshd
2) Who: User groups: ops, Accessing: Host groups: prod, Via service: sshd
3) Who: Anyone, Accessing: Host groups: test, Via service: sshd

That's somewhat fine, but I dislike the "allow_all_but_ssh" rule there.
Reason: I manually have to select every service and remove sshd. But if
a new service were to be added, I'd have to remember to add it there as
well. Not cool. Even more so, because I'm not the only admin. Colleagues
would have to know this as well. Not cool².

Somehow I'm missing "deny"-rules, I think. Nice to have allow rules,
but I'm rather looking for a way to deny something :/

Don't know, but that seems to be too complicated. Or is that really the
way to do that?

Thanks a lot,

Alexander
-- 
=>Google+ => http://plus.skwar.me <==
=> Chat (Jabber/Google Talk) => a.sk...@gmail.com <==

-- 
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] HBAC - Limit SSH access to "test" systems

[Alexander Bokovoy]

On Mon, 30 Nov 2015, Alexander Skwar wrote:

Hello

I'm trying to setup our FreeIPA 4.1.0 (RHEL 7) servers with Ubuntu 14.04
FreeIPA 3.3.4 clients so, that users in a user group called "customers"
can only access hosts, which are in a host group called "test". Users
from the user group "ops" should be able to access all systems (ie.
"prod" systems and also those "test" systems).

But I cannot get my head around to create proper HBAC rules/setup…

Could somebody maybe lend me a helping hand?

At the moment, I have set it up so, that I modified the "prod" systems
sshd_config and added "DenyGroups customer" there. On the test systems,
I don't have that line. That works, but it's not using IPA (in a sense…
I do have to modify the hosts configuration on the system, which I
dislike. Granted, with Chef, it's not much, but still *G*).

HBAC is enforced by SSSD over PAM. All you need to ensure is that an
application (sshd in this case) uses PAM. Then you setup HBAC rules,
disable allow_all rule, and then SSSD will verify rules on logon via
sshd, checking all rules for service 'sshd' and applying to this host
(via hostgroup or to all hosts).

--
/ Alexander Bokovoy

--
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] HBAC - Limit SSH access to "test" systems

[Alexander Skwar]

Hello

I'm trying to setup our FreeIPA 4.1.0 (RHEL 7) servers with Ubuntu 14.04
FreeIPA 3.3.4 clients so, that users in a user group called "customers"
can only access hosts, which are in a host group called "test". Users
from the user group "ops" should be able to access all systems (ie.
"prod" systems and also those "test" systems).

But I cannot get my head around to create proper HBAC rules/setup…

Could somebody maybe lend me a helping hand?

At the moment, I have set it up so, that I modified the "prod" systems
sshd_config and added "DenyGroups customer" there. On the test systems,
I don't have that line. That works, but it's not using IPA (in a sense…
I do have to modify the hosts configuration on the system, which I
dislike. Granted, with Chef, it's not much, but still *G*).


Thanks,

Alexander
-- 
=>Google+ => http://plus.skwar.me <==
=> Chat (Jabber/Google Talk) => a.sk...@gmail.com <==

-- 
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] hbac service allowed despite not listed

[Alexander Bokovoy]

On Tue, 24 Nov 2015, Winfried de Heiden wrote:


Hi all,

The problem is clear, there is a misunderstanding of the service "su" 
and "su-l", this is about the target users. Hence; su - to user 
winfried is allowed since su and su-l are added to the hbac service 
list of this user.


This looks a bit strange from the ui perspective, all other HBAC 
services are what this user is allow to do; "su" and "su-l" defines 
that OTHER user may become this user by using su.


A bit strange, but this is how is works. Anyone disagree?

Consider the fact that HBAC names are names of PAM services used by
applications.  If an application uses PAM, it specifies name of own
configuration file relative to /etc/pam.d toPAM API.

For 'su' utility look into its manual page, section FILES:
FILES
  /etc/pam.d/sudefault PAM configuration file
  /etc/pam.d/su-l  PAM configuration file if --login is specified
  /etc/default/su  command specific logindef config file
  /etc/login.defs  global logindef config file

'su' utility uses two different PAM names for different modes of
operation. Therefore, when defining HBAC rules for 'su' you need to take
into account both PAM services and decide what you want to do with them.




Winny





Op 24-11-15 om 14:04 schreef Jakub Hrozek:

On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote:

Hi all,

[winfried@ipa ~]$ ipa hbacrule-show allow_all
  Rule name: allow_all
  User category: all
  Host category: all
  Service category: all
  Description: Allow all users to access any host from any host
  Enabled: FALSE

[winfried@ipa ~]$ ipa hbacrule-show testuser
  Rule name: testuser
  Enabled: TRUE
  Users: testuser
  Hosts: fedora23-server.blabla.bla
  Services: sshd

[winfried@ipa ~]$ ipa user-show winfried
  User login: winfried
  First name: Winfried
  Last name: de Heiden
  Home directory: /home/winfried
  Login shell: /bin/bash
etc. .etc.

[winfried@ipa ~]$ ipa user-show testuser
  User login: testuser
  First name: test
  Last name: user
  Home directory: /home/testuser
  Login shell: /bin/bash
  Email address: testu...@blabla.bla
  UID: 10005
  GID: 10005
  Account disabled: False
  Password: True
  Member of groups: ipausers
  Member of HBAC rule: testuser
  Kerberos keys available: True



[[testuser@fedora23-server ~]$ su winfried
Wachtwoord:
[winfried@fedora23-server testuser]$ id
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),1(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

So yes, I can su to another IPA-user :(

sssd_pam now shows information, but nothing seems to go wrong...

I think you forgot to CC freeipa-users.

In this case, can you look into /var/log/secure again and into the
domain logs?


What's happening?

Winny

Op 24-11-15 om 11:43 schreef Jakub Hrozek:

On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:

   Hi all,

   Running as an ordinary user, straight from the beginning.

   Is the (default) suid of/usr/bin/su causing this?
   Anyway: the info requested:

   /var/log/secure will tell:
   Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
   session: Already running in a session
   Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
   for user root by testuser(uid=10005)

 

Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
would do:
pam_start("su", "root", ...)
pam_authenticate();

So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.


--
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


--
/ Alexander Bokovoy

--
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] hbac service allowed despite not listed

[Winfried de Heiden]

Hi all,

The problem is clear, there is a misunderstanding of the service "su" 
and "su-l", this is about the target users. Hence; su - to user winfried 
is allowed since su and su-l are added to the hbac service list of this 
user.


This looks a bit strange from the ui perspective, all other HBAC 
services are what this user is allow to do; "su" and "su-l" defines that 
OTHER user may become this user by using su.


A bit strange, but this is how is works. Anyone disagree?

Winny





Op 24-11-15 om 14:04 schreef Jakub Hrozek:

On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote:

Hi all,

[winfried@ipa ~]$ ipa hbacrule-show allow_all
   Rule name: allow_all
   User category: all
   Host category: all
   Service category: all
   Description: Allow all users to access any host from any host
   Enabled: FALSE

[winfried@ipa ~]$ ipa hbacrule-show testuser
   Rule name: testuser
   Enabled: TRUE
   Users: testuser
   Hosts: fedora23-server.blabla.bla
   Services: sshd

[winfried@ipa ~]$ ipa user-show winfried
   User login: winfried
   First name: Winfried
   Last name: de Heiden
   Home directory: /home/winfried
   Login shell: /bin/bash
etc. .etc.

[winfried@ipa ~]$ ipa user-show testuser
   User login: testuser
   First name: test
   Last name: user
   Home directory: /home/testuser
   Login shell: /bin/bash
   Email address: testu...@blabla.bla
   UID: 10005
   GID: 10005
   Account disabled: False
   Password: True
   Member of groups: ipausers
   Member of HBAC rule: testuser
   Kerberos keys available: True



[[testuser@fedora23-server ~]$ su winfried
Wachtwoord:
[winfried@fedora23-server testuser]$ id
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),1(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

So yes, I can su to another IPA-user :(

sssd_pam now shows information, but nothing seems to go wrong...

I think you forgot to CC freeipa-users.

In this case, can you look into /var/log/secure again and into the
domain logs?


What's happening?

Winny

Op 24-11-15 om 11:43 schreef Jakub Hrozek:

On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:

Hi all,

Running as an ordinary user, straight from the beginning.

Is the (default) suid of/usr/bin/su causing this?
Anyway: the info requested:

/var/log/secure will tell:
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)

  

Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
would do:
 pam_start("su", "root", ...)
 pam_authenticate();

So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.


--
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] hbac service allowed despite not listed

[Jakub Hrozek]

On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote:
> Hi all,
> 
> [winfried@ipa ~]$ ipa hbacrule-show allow_all
>   Rule name: allow_all
>   User category: all
>   Host category: all
>   Service category: all
>   Description: Allow all users to access any host from any host
>   Enabled: FALSE
> 
> [winfried@ipa ~]$ ipa hbacrule-show testuser
>   Rule name: testuser
>   Enabled: TRUE
>   Users: testuser
>   Hosts: fedora23-server.blabla.bla
>   Services: sshd
> 
> [winfried@ipa ~]$ ipa user-show winfried
>   User login: winfried
>   First name: Winfried
>   Last name: de Heiden
>   Home directory: /home/winfried
>   Login shell: /bin/bash
> etc. .etc.
> 
> [winfried@ipa ~]$ ipa user-show testuser
>   User login: testuser
>   First name: test
>   Last name: user
>   Home directory: /home/testuser
>   Login shell: /bin/bash
>   Email address: testu...@blabla.bla
>   UID: 10005
>   GID: 10005
>   Account disabled: False
>   Password: True
>   Member of groups: ipausers
>   Member of HBAC rule: testuser
>   Kerberos keys available: True
> 
> 
> 
> [[testuser@fedora23-server ~]$ su winfried
> Wachtwoord:
> [winfried@fedora23-server testuser]$ id
> UID=10001(winfried) GID=10001(winfried)
> groepen=10001(winfried),1(admins),10003(linuxadmins),10004(linuxusers)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> 
> So yes, I can su to another IPA-user :(
> 
> sssd_pam now shows information, but nothing seems to go wrong...

I think you forgot to CC freeipa-users.

In this case, can you look into /var/log/secure again and into the
domain logs?

> 
> What's happening?
> 
> Winny
> 
> Op 24-11-15 om 11:43 schreef Jakub Hrozek:
> >On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:
> >>Hi all,
> >>
> >>Running as an ordinary user, straight from the beginning.
> >>
> >>Is the (default) suid of/usr/bin/su causing this?
> >>Anyway: the info requested:
> >>
> >>/var/log/secure will tell:
> >>Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot 
> >> create
> >>session: Already running in a session
> >>Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
> >>for user root by testuser(uid=10005)
> >  
> >
> >Sorry, I missed this previously. So you're running "su -" as testuser
> >right? That's not hitting SSSD, because the target user is root, so "su"
> >would do:
> > pam_start("su", "root", ...)
> > pam_authenticate();
> >
> >So what you're seeing is expected. Try su-ing to testuser from another
> >non-root user, it's going to fail.
> 

-- 
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] hbac service allowed despite not listed

[Jakub Hrozek]

On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:
>Hi all,
> 
>Running as an ordinary user, straight from the beginning.
> 
>Is the (default) suid of/usr/bin/su causing this?
> 
>Anyway: the info requested:
> 
>/var/log/secure will tell:
>Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
>session: Already running in a session
>Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
>for user root by testuser(uid=10005)
 

Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
would do:
pam_start("su", "root", ...)
pam_authenticate();

So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.

-- 
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] hbac service allowed despite not listed

[Jakub Hrozek]

On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:
>Hi all,
> 
>Running as an ordinary user, straight from the beginning.
> 
>Is the (default) suid of/usr/bin/su causing this?
> 
>Anyway: the info requested:
> 
>/var/log/secure will tell:
>Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
>session: Already running in a session
>Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
>for user root by testuser(uid=10005)

Interesting, there is even no account message at all...not even auth
message?

> 
>De pam.d files are from a clean fresh Fedora23 install and
>ipa-client-install afterwards:
> 
>/etc/pam.d/su
>#%PAM-1.0
>auth        sufficient    pam_rootok.so
># Uncomment the following line to implicitly trust users in the "wheel"
>group.
>#auth        sufficient    pam_wheel.so trust use_uid
># Uncomment the following line to require a user to be in the "wheel"
>group.
>#auth        required    pam_wheel.so use_uid
>auth        substack    system-auth
>auth        include        postlogin
>account        sufficient    pam_succeed_if.so uid = 0 use_uid quiet
>account        include        system-auth

...yet clearly here su includes system_auth unless pam_succeed_if ran
(which should only happen if you ran su as root)

Just to be sure, can you comment out the pam_succeed_if.so line?

>password    include        system-auth
>session        include        system-auth
>session        include        postlogin
>session        optional    pam_xauth.so
> 
>/etc/pam.d/postlogin
>#%PAM-1.0
># This file is auto-generated.
># User changes will be destroyed the next time authconfig is run.
>session [success=1 default=ignore] pam_succeed_if.so service !~ gdm*
>service !~ su* quiet
>session [default=1]   pam_lastlog.so nowtmp silent
>session optional  pam_lastlog.so silent noupdate showfailed
> 
>/etc/pam.d/system-auth
>#%PAM-1.0
># This file is auto-generated.
># User changes will be destroyed the next time authconfig is run.
>auth    required  pam_env.so
>auth    [default=1 success=ok] pam_localuser.so
>auth    [success=done ignore=ignore default=die] pam_unix.so nullok
>try_first_pass
>auth    requisite pam_succeed_if.so uid >= 1000 quiet_success
>auth    sufficient    pam_sss.so forward_pass
>auth    required  pam_deny.so
> 
>account required  pam_unix.so
>account sufficient    pam_localuser.so
>account sufficient    pam_succeed_if.so uid < 1000 quiet
>account [default=bad success=ok user_unknown=ignore] pam_sss.so
>account required  pam_permit.so
> 
>password    requisite pam_pwquality.so try_first_pass local_users_only
>retry=3 authtok_type=
>password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass
>use_authtok
>password    sufficient    pam_sss.so use_authtok
>password    required  pam_deny.so
> 
>session optional  pam_keyinit.so revoke
>session required  pam_limits.so
>-session optional  pam_systemd.so
>session optional  pam_oddjob_mkhomedir.so umask=0077
>session [success=1 default=ignore] pam_succeed_if.so service in crond
>quiet use_uid
>session required  pam_unix.so
>session optional  pam_sss.so
> 
>Op 24-11-15 om 10:37 schreef Jakub Hrozek:
> 
>  re you running su as an ordinary user or root? What does appear in
>  /var/log/secure when you run su ?
> 
>  Can you show what is the /etc/pam.d/su config and the config of the
>  service that is included from /etc/pam.d/su ? (typically system-auth)

-- 
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] hbac service allowed despite not listed

[Winfried de Heiden]

  
  
Hi all,
  
  Running as an ordinary user, straight from the beginning.
  
  Is the (default) suid of/usr/bin/su causing this? 
   
  Anyway: the info requested:
  
  /var/log/secure will tell:
  Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session):
  Cannot create session: Already running in a session
  Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session
  opened for user root by testuser(uid=10005)
  
  De pam.d files are from a clean fresh Fedora23 install and
  ipa-client-install afterwards:
  
  /etc/pam.d/su
  #%PAM-1.0
  auth        sufficient    pam_rootok.so
  # Uncomment the following line to implicitly trust users in the
  "wheel" group.
  #auth        sufficient    pam_wheel.so trust use_uid
  # Uncomment the following line to require a user to be in the
  "wheel" group.
  #auth        required    pam_wheel.so use_uid
  auth        substack    system-auth
  auth        include        postlogin
  account        sufficient    pam_succeed_if.so uid = 0 use_uid
  quiet
  account        include        system-auth
  password    include        system-auth
  session        include        system-auth
  session        include        postlogin
  session        optional    pam_xauth.so
  
  /etc/pam.d/postlogin
  #%PAM-1.0
  # This file is auto-generated.
  # User changes will be destroyed the next time authconfig is run.
  session [success=1 default=ignore] pam_succeed_if.so service
  !~ gdm* service !~ su* quiet
  session [default=1]   pam_lastlog.so nowtmp silent
  session optional  pam_lastlog.so silent noupdate
  showfailed
  
  /etc/pam.d/system-auth
  #%PAM-1.0
  # This file is auto-generated.
  # User changes will be destroyed the next time authconfig is run.
  auth    required  pam_env.so
  auth    [default=1 success=ok] pam_localuser.so
  auth    [success=done ignore=ignore default=die] pam_unix.so
  nullok try_first_pass
  auth    requisite pam_succeed_if.so uid >= 1000
  quiet_success
  auth    sufficient    pam_sss.so forward_pass
  auth    required  pam_deny.so
  
  account required  pam_unix.so
  account sufficient    pam_localuser.so
  account sufficient    pam_succeed_if.so uid < 1000 quiet
  account [default=bad success=ok user_unknown=ignore]
  pam_sss.so
  account required  pam_permit.so
  
  password    requisite pam_pwquality.so try_first_pass
  local_users_only retry=3 authtok_type=
  password    sufficient    pam_unix.so sha512 shadow nullok
  try_first_pass use_authtok
  password    sufficient    pam_sss.so use_authtok
  password    required  pam_deny.so
  
  session optional  pam_keyinit.so revoke
  session required  pam_limits.so
  -session optional  pam_systemd.so
  session optional  pam_oddjob_mkhomedir.so umask=0077
  session [success=1 default=ignore] pam_succeed_if.so service
  in crond quiet use_uid
  session required  pam_unix.so
  session optional  pam_sss.so
  

Op 24-11-15 om 10:37 schreef Jakub
  Hrozek:


  re you running su as an ordinary user or root? What does appear in
/var/log/secure when you run su ?

Can you show what is the /etc/pam.d/su config and the config of the
service that is included from /etc/pam.d/su ? (typically system-auth)



  


-- 
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] hbac service allowed despite not listed

[Jakub Hrozek]

On Tue, Nov 24, 2015 at 10:25:11AM +0100, Winfried de Heiden wrote:
>Hi all,
> 
>sss_debuglevel 6; in /var/log/sss/sssd_pam.log
> 
>Running as "testuser" crond is denied; perfecr since it is not listed in
>the HBAC services.
> 
>[testuser@fedora23-server ~]$ crontab -l
>You (testuser) are not allowed to access to (crontab) because of pam
>configuration.
> 
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [accept_fd_handler] (0x0400):
>Client connected!
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
>Received client version [3].
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version] (0x0200):
>Offered version [3].
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100):
>entering pam_cmd_acct_mgmt
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_parse_name_for_domains]
>(0x0200): name 'testuser' matched without domain, user is testuser
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
>SSS_PAM_ACCT_MGMT
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
>not set
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
>testuser
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
>crond
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): tty:
>cron
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>not set
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>not set
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
>type: 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
>newauthtok type: 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
>1910
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>name: testuser
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400):
>Issuing request for [[1]0x561eb0a4b2e0:3:testu...@blabla.bla]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400):
>Creating request for
>[blabla.bla][0x3][BE_REQ_INITGROUPS][1][name=testuser]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_internal_get_send]
>(0x0400): Entering request [[2]0x561eb0a4b2e0:3:testu...@blabla.bla]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search] (0x0100):
>Requesting info for [[3]testu...@blabla.bla]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search] (0x0400):
>Returning info for user [[4]testu...@blabla.bla]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
>request with the following data:
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): command:
>SSS_PAM_ACCT_MGMT
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): domain:
>blabla.bla
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): user:
>testuser
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): service:
>crond
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): tty:
>cron
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser:
>not set
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost:
>not set
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok
>type: 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
>newauthtok type: 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
>1910
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100): logon
>name: testuser
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100):
>pam_dp_send_req returned 0
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400):
>Deleting request: [[5]0x561eb0a4b2e0:3:testu...@blabla.bla]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_process_reply] (0x0200):
>received: [6 (Permission denied)][blabla.bla]
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply
>called with result [6]: Permission denied.
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27
>(Tue Nov 24 09:54:58 2015) [sssd[pam]] [client_recv] (0x0200): Client
>disconnected!
> 
>Now, using su or su - does not show anything in de sssd logs, it looks
>like the su service is not using sssd. What could be wrong?

Are you running su as an ordinary user or root? What does appear in
/var/log/secure when you run su ?

Can you show what is the /etc/pam.d/su config and the config of the
service that is included from /etc/

Re: [Freeipa-users] hbac service allowed despite not listed

[Winfried de Heiden]

  
  
Hi all,
  
  sss_debuglevel 6; in /var/log/sss/sssd_pam.log
  
  
  Running as "testuser" crond is denied; perfecr since it is not
  listed in the HBAC services.
  
  [testuser@fedora23-server ~]$ crontab -l
  You (testuser) are not allowed to access to (crontab) because of
  pam configuration.
  
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [accept_fd_handler]
  (0x0400): Client connected!
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version]
  (0x0200): Received client version [3].
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_cmd_get_version]
  (0x0200): Offered version [3].
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_cmd_acct_mgmt]
  (0x0100): entering pam_cmd_acct_mgmt
  (Tue Nov 24 09:54:58 2015) [sssd[pam]]
  [sss_parse_name_for_domains] (0x0200): name 'testuser' matched
  without domain, user is testuser
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  command: SSS_PAM_ACCT_MGMT
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  domain: not set
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  user: testuser
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  service: crond
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  tty: cron
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  ruser: not set
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  rhost: not set
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  authtok type: 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  newauthtok type: 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  priv: 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  cli_pid: 1910
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  logon name: testuser
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_issue_request]
  (0x0400): Issuing request for
  [0x561eb0a4b2e0:3:testu...@blabla.bla]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_get_account_msg]
  (0x0400): Creating request for
  [blabla.bla][0x3][BE_REQ_INITGROUPS][1][name=testuser]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_internal_get_send]
  (0x0400): Entering request [0x561eb0a4b2e0:3:testu...@blabla.bla]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search]
  (0x0100): Requesting info for [testu...@blabla.bla]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_check_user_search]
  (0x0400): Returning info for user [testu...@blabla.bla]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_send_req] (0x0100):
  Sending request with the following data:
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  command: SSS_PAM_ACCT_MGMT
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  domain: blabla.bla
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  user: testuser
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  service: crond
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  tty: cron
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  ruser: not set
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  rhost: not set
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  authtok type: 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  newauthtok type: 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  priv: 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  cli_pid: 1910
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_print_data] (0x0100):
  logon name: testuser
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dom_forwarder]
  (0x0100): pam_dp_send_req returned 0
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [sss_dp_req_destructor]
  (0x0400): Deleting request: [0x561eb0a4b2e0:3:testu...@blabla.bla]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_dp_process_reply]
  (0x0200): received: [6 (Permission denied)][blabla.bla]
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200):
  pam_reply called with result [6]: Permission denied.
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [pam_reply] (0x0200): blen:
  27
  (Tue Nov 24 09:54:58 2015) [sssd[pam]] [client_recv] (0x0200):
  Client disconnected!
  
  Now, using su or su - does not show anything in de sssd logs, it
  looks like the su service is not using sssd. What could be wrong?
  
  forgot to mention; allow_all is disabled, checked that 100
  times...
  
  Kind regards,
  
  Winny
  

Re: [Freeipa-users] hbac service allowed despite not listed

[Sumit Bose]

On Mon, Nov 23, 2015 at 05:16:26PM +0100, Jakub Hrozek wrote:
> On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote:
> >Hi all,
> > 
> >I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
> > 
> ># ipa hbacrule-show testuser
> >  Rule name: testuser
> >  Enabled: TRUE
> >  Users: testuser
> >  Hosts: fedora23-server.blabla.bla
> >  Services: sshd
> > 
> >Hence, " testuser"  is only allowed using sshd on "fedora23-server". No
> >surprise, this user is not allowed to use "su":
> > 
> ># ipa hbactest --user testuser --host fedora23-server.blabla.bla 
> > --service
> >su
> >-
> >Access granted: False
> > 
> >(and yeah sshd is allowed)
> > 
> >However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
> >correct password, access is granted. This user is not a member of any
> >other groups.
> >HBAC Services like cron or console access are denied correctly since they
> >are not in the HBAC service list.
> > 
> >I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several
> >other ipa-clients (RHEL/CentoOS 6.x, 7.x)
> > 
> >Shouldn't su or su -l be denied when not listed?
> 
> Yes, and in my testing with a similar rule:
> 
> $ ipa hbacrule-show allow_sshd
>   Rule name: allow_sshd
>   Enabled: TRUE
>   Users: admin
>   Hosts: client.ipa.test
>   Services: sshd
> 
> admin can ssh to client.ipa.test but it's not possible to su to admin.
> 
> Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check
> /var/log/secure and the sssd logs.
> 
> Also, you're not calling su as root, are you?

Have you disabled the allow_all rule?

bye,
Sumit

> 
> -- 
> 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

-- 
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] hbac service allowed despite not listed

[Jakub Hrozek]

On Mon, Nov 23, 2015 at 04:55:31PM +0100, Winfried de Heiden wrote:
>Hi all,
> 
>I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
> 
># ipa hbacrule-show testuser
>  Rule name: testuser
>  Enabled: TRUE
>  Users: testuser
>  Hosts: fedora23-server.blabla.bla
>  Services: sshd
> 
>Hence, " testuser"  is only allowed using sshd on "fedora23-server". No
>surprise, this user is not allowed to use "su":
> 
># ipa hbactest --user testuser --host fedora23-server.blabla.bla --service
>su
>-
>Access granted: False
> 
>(and yeah sshd is allowed)
> 
>However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
>correct password, access is granted. This user is not a member of any
>other groups.
>HBAC Services like cron or console access are denied correctly since they
>are not in the HBAC service list.
> 
>I noticed this behaviour also on IPA 4.1 (The Red Hat one) and several
>other ipa-clients (RHEL/CentoOS 6.x, 7.x)
> 
>Shouldn't su or su -l be denied when not listed?

Yes, and in my testing with a similar rule:

$ ipa hbacrule-show allow_sshd
  Rule name: allow_sshd
  Enabled: TRUE
  Users: admin
  Hosts: client.ipa.test
  Services: sshd

admin can ssh to client.ipa.test but it's not possible to su to admin.

Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and check
/var/log/secure and the sssd logs.

Also, you're not calling su as root, are you?

-- 
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] hbac service allowed despite not listed

[Winfried de Heiden]

  
  
Hi all,
  
  I created some hbac rule on freeipa-server 4.1.4 on Fedora 22
  
  # ipa hbacrule-show testuser
    Rule name: testuser
    Enabled: TRUE
    Users: testuser
    Hosts: fedora23-server.blabla.bla
    Services: sshd
  
  Hence, " testuser"  is only allowed using sshd on
  "fedora23-server". No surprise, this user is not allowed to use
  "su":
  
  # ipa hbactest --user testuser --host fedora23-server.blabla.bla
  --service su
  -
  Access granted: False
  
  (and yeah sshd is allowed)
  
  However, doing a "su"  on the fedora23-server.blabla.bla, and giving the
correct password, access is granted. This user is not a member
of any other groups.
HBAC Services like cron or console access are denied correctly
since they are not in the HBAC service list.

I noticed this behaviour also on IPA 4.1 (The Red Hat one) and
several other ipa-clients (RHEL/CentoOS 6.x, 7.x)

Shouldn't su or su -l be denied when not listed?

Kind regards,

Winny

   
  


-- 
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] HBAC

[TomK]

On 10/1/2015 12:04 PM, Simo Sorce wrote:

On 30/09/15 21:22, TomK wrote:



On 9/30/2015 8:12 AM, Martin Kosek wrote:

On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the
freeipa-users
mailing list so not sure if the other message will get posted.)

Before I post a ticket to RH Support for an RFE, I'll post the
request here
to get some feedback on options and what ideas folks have.  I've a
situation
as follows.  I have the following setup in WS 2012 AD DC:

TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper
RFC for
LDAP.  With SSSD rules I can define the rules to read the user 'host'
attribute but not the group 'host' attribute:


|access_provider = ldap ldap_access_order = host
ldap_user_authorized_host =
host|


Essentially TomK to be given access to hosts listed in the 'host'
attribute
but denied entry into lab05 for example (not listed in any group 
'host'

attribute above) to the server.   If I have a new user that has
joined that
particular team at our organization, I can simply add her/him to the
above
groups and this user would get access only to the listed servers in
'host'
attribute by default. I don't need to specify new groups in 
customized

sssd.conf or ldap.conf files or in sshd config files. Hence less to
update
with Salt or any other CM suite.  I've managed to setup SUDO rules
and with
the openssh-ldap.diff schema SSH public keys could be stored in AD
as well
and be read by OpenSSH.  So aside from the HBAC capability on groups,
virtually all our needs are handled by the WS2012 AD DC as it has to
follow
the OpenLDAP standard anyway.  Now to get this we considered and are
still
considering FreeIPA.  However this idea poses a set of challenges:

1) In large organizations where the AD support department are only
trained in
Windows AD setup and configuration (Only windows guy's) this would
require a
minimal of 3 bodies to support that know LDAP/Linux.  This is a
large cost.

2) The additional server requires the same hardening as the Windows
AD DC
servers meaning a new procedure has to be carved out for the 2+ 
FreeIPA

servers to be supported, hardened and maintained (upgraded).

Now I probably sound somewhat anti-FreeIPA, however the challenges of
implementing it in large organizations surface after some
deliberation, so
probably better to list then as it may help direct development of
the product
to contend with the challenges (Like having a document fully
dedicated to
hardening a FreeIPA server with selinux and other technologies in
easy to
maintain configuration).   I could be mistaken but some folks
mention that
it's 'better' to implement this sort of HBAC through other means (??
iptables
??) but never tried the alternatives yet.

So, cutting to the end, would it be possible to add an attribute 
like:


|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to
enable
reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups 
and

then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html 




More reading on External groups used for AD access control:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups 




I would also suggest a video with HBAC and Trust in action:

https://www.youtube.com/watch?v=sQnNFJOzwa8

HTH,
Martin


We already defined HBAC rules in the manner that all the links you
pointed out indicate as an early implementation.  As a product, there is
no issue in IDM from that perspective.  This is all great and the
product is fine from that perspective.

It would be good to have a dual option of either allowing SSSD or IDM /
FreeIPA have full HBAC capability not just FreeIPA / IDM as in our
organization that would be a huge cost savings vs implementing IDM as a
separate Linux DC to be managed by a separate team.  So for those
customers that wish to go directly to AD or have already invested in AD
can choose SSSD only (If MS bundles AD with certain purchases, for
example, that is an actual cost savings for a company).  Other customers
who wish to keep the two separate so they do not flood AD DC's with non
Windows AD settings can integrate IDM.

There will be cases where there could be a potential to save on costs vs
AD so the Linux IDM 

Re: [Freeipa-users] HBAC

[Simo Sorce]

On 30/09/15 21:22, TomK wrote:



On 9/30/2015 8:12 AM, Martin Kosek wrote:

On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the
freeipa-users
mailing list so not sure if the other message will get posted.)

Before I post a ticket to RH Support for an RFE, I'll post the
request here
to get some feedback on options and what ideas folks have.  I've a
situation
as follows.  I have the following setup in WS 2012 AD DC:

TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper
RFC for
LDAP.  With SSSD rules I can define the rules to read the user 'host'
attribute but not the group 'host' attribute:


|access_provider = ldap ldap_access_order = host
ldap_user_authorized_host =
host|


Essentially TomK to be given access to hosts listed in the 'host'
attribute
but denied entry into lab05 for example (not listed in any group 'host'
attribute above) to the server.   If I have a new user that has
joined that
particular team at our organization, I can simply add her/him to the
above
groups and this user would get access only to the listed servers in
'host'
attribute by default. I don't need to specify new groups in customized
sssd.conf or ldap.conf files or in sshd config files.  Hence less to
update
with Salt or any other CM suite.  I've managed to setup SUDO rules
and with
the openssh-ldap.diff schema SSH public keys could be stored in AD
as well
and be read by OpenSSH.  So aside from the HBAC capability on groups,
virtually all our needs are handled by the WS2012 AD DC as it has to
follow
the OpenLDAP standard anyway.  Now to get this we considered and are
still
considering FreeIPA.  However this idea poses a set of challenges:

1) In large organizations where the AD support department are only
trained in
Windows AD setup and configuration (Only windows guy's) this would
require a
minimal of 3 bodies to support that know LDAP/Linux.  This is a
large cost.

2) The additional server requires the same hardening as the Windows
AD DC
servers meaning a new procedure has to be carved out for the 2+ FreeIPA
servers to be supported, hardened and maintained (upgraded).

Now I probably sound somewhat anti-FreeIPA, however the challenges of
implementing it in large organizations surface after some
deliberation, so
probably better to list then as it may help direct development of
the product
to contend with the challenges (Like having a document fully
dedicated to
hardening a FreeIPA server with selinux and other technologies in
easy to
maintain configuration).   I could be mistaken but some folks
mention that
it's 'better' to implement this sort of HBAC through other means (??
iptables
??) but never tried the alternatives yet.

So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to
enable
reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups and
then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html


More reading on External groups used for AD access control:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups


I would also suggest a video with HBAC and Trust in action:

https://www.youtube.com/watch?v=sQnNFJOzwa8

HTH,
Martin


We already defined HBAC rules in the manner that all the links you
pointed out indicate as an early implementation.  As a product, there is
no issue in IDM from that perspective.  This is all great and the
product is fine from that perspective.

It would be good to have a dual option of either allowing SSSD or IDM /
FreeIPA have full HBAC capability not just FreeIPA / IDM as in our
organization that would be a huge cost savings vs implementing IDM as a
separate Linux DC to be managed by a separate team.  So for those
customers that wish to go directly to AD or have already invested in AD
can choose SSSD only (If MS bundles AD with certain purchases, for
example, that is an actual cost savings for a company).  Other customers
who wish to keep the two separate so they do not flood AD DC's with non
Windows AD settings can integrate IDM.

There will be cases where there could be a potential to save on costs vs
AD so the Linux IDM could be chosen as an Enterprise DC to which Windows
server

Re: [Freeipa-users] HBAC

[TomK]

On 9/30/2015 8:12 AM, Martin Kosek wrote:

On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the freeipa-users
mailing list so not sure if the other message will get posted.)

Before I post a ticket to RH Support for an RFE, I'll post the request here
to get some feedback on options and what ideas folks have.  I've a situation
as follows.  I have the following setup in WS 2012 AD DC:

TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper RFC for
LDAP.  With SSSD rules I can define the rules to read the user 'host'
attribute but not the group 'host' attribute:


|access_provider = ldap ldap_access_order = host ldap_user_authorized_host =
host|


Essentially TomK to be given access to hosts listed in the 'host' attribute
but denied entry into lab05 for example (not listed in any group 'host'
attribute above) to the server.   If I have a new user that has joined that
particular team at our organization, I can simply add her/him to the above
groups and this user would get access only to the listed servers in 'host'
attribute by default. I don't need to specify new groups in customized
sssd.conf or ldap.conf files or in sshd config files.  Hence less to update
with Salt or any other CM suite.  I've managed to setup SUDO rules and with
the openssh-ldap.diff schema SSH public keys could be stored in AD as well
and be read by OpenSSH.  So aside from the HBAC capability on groups,
virtually all our needs are handled by the WS2012 AD DC as it has to follow
the OpenLDAP standard anyway.  Now to get this we considered and are still
considering FreeIPA.  However this idea poses a set of challenges:

1) In large organizations where the AD support department are only trained in
Windows AD setup and configuration (Only windows guy's) this would require a
minimal of 3 bodies to support that know LDAP/Linux.  This is a large cost.

2) The additional server requires the same hardening as the Windows AD DC
servers meaning a new procedure has to be carved out for the 2+ FreeIPA
servers to be supported, hardened and maintained (upgraded).

Now I probably sound somewhat anti-FreeIPA, however the challenges of
implementing it in large organizations surface after some deliberation, so
probably better to list then as it may help direct development of the product
to contend with the challenges (Like having a document fully dedicated to
hardening a FreeIPA server with selinux and other technologies in easy to
maintain configuration).   I could be mistaken but some folks mention that
it's 'better' to implement this sort of HBAC through other means (?? iptables
??) but never tried the alternatives yet.

So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to enable
reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups and
then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html

More reading on External groups used for AD access control:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups

I would also suggest a video with HBAC and Trust in action:

https://www.youtube.com/watch?v=sQnNFJOzwa8

HTH,
Martin


We already defined HBAC rules in the manner that all the links you 
pointed out indicate as an early implementation.  As a product, there is 
no issue in IDM from that perspective.  This is all great and the 
product is fine from that perspective.


It would be good to have a dual option of either allowing SSSD or IDM / 
FreeIPA have full HBAC capability not just FreeIPA / IDM as in our 
organization that would be a huge cost savings vs implementing IDM as a 
separate Linux DC to be managed by a separate team.  So for those 
customers that wish to go directly to AD or have already invested in AD 
can choose SSSD only (If MS bundles AD with certain purchases, for 
example, that is an actual cost savings for a company).  Other customers 
who wish to keep the two separate so they do not flood AD DC's with non 
Windows AD settings can integrate IDM.


There will be cases where there could be a potential to save on costs vs 
AD so the Linux IDM could be chosen as an Enterprise DC to which Windows 
server authenticate as we

Re: [Freeipa-users] HBAC

[Martin Kosek]

On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:
> On Tue, 29 Sep 2015, TomK wrote:
>> Hey Guy's,
>>
>> (Sending this again as I didn't have this email included in the freeipa-users
>> mailing list so not sure if the other message will get posted.)
>>
>> Before I post a ticket to RH Support for an RFE, I'll post the request here
>> to get some feedback on options and what ideas folks have.  I've a situation
>> as follows.  I have the following setup in WS 2012 AD DC:
>>
>> TomK (user)
>> TomK Groups:
>>unixg
>>windowsg
>>
>> unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
>> windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'
>>
>> TomK(user) also has the 'host' attribute defined as per the proper RFC for
>> LDAP.  With SSSD rules I can define the rules to read the user 'host'
>> attribute but not the group 'host' attribute:
>>
>>
>> |access_provider = ldap ldap_access_order = host ldap_user_authorized_host =
>> host|
>>
>>
>> Essentially TomK to be given access to hosts listed in the 'host' attribute
>> but denied entry into lab05 for example (not listed in any group 'host'
>> attribute above) to the server.   If I have a new user that has joined that
>> particular team at our organization, I can simply add her/him to the above
>> groups and this user would get access only to the listed servers in 'host'
>> attribute by default. I don't need to specify new groups in customized
>> sssd.conf or ldap.conf files or in sshd config files.  Hence less to update
>> with Salt or any other CM suite.  I've managed to setup SUDO rules and with
>> the openssh-ldap.diff schema SSH public keys could be stored in AD as well
>> and be read by OpenSSH.  So aside from the HBAC capability on groups,
>> virtually all our needs are handled by the WS2012 AD DC as it has to follow
>> the OpenLDAP standard anyway.  Now to get this we considered and are still
>> considering FreeIPA.  However this idea poses a set of challenges:
>>
>> 1) In large organizations where the AD support department are only trained in
>> Windows AD setup and configuration (Only windows guy's) this would require a
>> minimal of 3 bodies to support that know LDAP/Linux.  This is a large cost.
>>
>> 2) The additional server requires the same hardening as the Windows AD DC
>> servers meaning a new procedure has to be carved out for the 2+ FreeIPA
>> servers to be supported, hardened and maintained (upgraded).
>>
>> Now I probably sound somewhat anti-FreeIPA, however the challenges of
>> implementing it in large organizations surface after some deliberation, so
>> probably better to list then as it may help direct development of the product
>> to contend with the challenges (Like having a document fully dedicated to
>> hardening a FreeIPA server with selinux and other technologies in easy to
>> maintain configuration).   I could be mistaken but some folks mention that
>> it's 'better' to implement this sort of HBAC through other means (?? iptables
>> ??) but never tried the alternatives yet.
>>
>> So, cutting to the end, would it be possible to add an attribute like:
>>
>> |ldap_user_authorized_host|
>>
>> but perhaps called 'ldap_group_authorized_host' to the SSSD code to enable
>> reading the 'host' attribute on AD/LDAP defined groups?
> In FreeIPA we support HBAC rules for AD users and groups. What exactly
> is wrong with that?
> 
> See 'ipa help trust' for details how to map AD groups to IPA groups and
> then 'ipa help hbacrule' for how to limit access of those groups to
> specific hosts and services on them.
> 
> This is all covered well in the guide:
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html

More reading on External groups used for AD access control:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups

I would also suggest a video with HBAC and Trust in action:

https://www.youtube.com/watch?v=sQnNFJOzwa8

HTH,
Martin

-- 
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] HBAC

[Alexander Bokovoy]

On Tue, 29 Sep 2015, TomK wrote:

Hey Guy's,

(Sending this again as I didn't have this email included in the 
freeipa-users mailing list so not sure if the other message will get 
posted.)


Before I post a ticket to RH Support for an RFE, I'll post the request 
here to get some feedback on options and what ideas folks have.  I've 
a situation as follows.  I have the following setup in WS 2012 AD DC:


TomK (user)
TomK Groups:
   unixg
   windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper RFC 
for LDAP.  With SSSD rules I can define the rules to read the user 
'host' attribute but not the group 'host' attribute:



|access_provider = ldap ldap_access_order = host 
ldap_user_authorized_host = host|



Essentially TomK to be given access to hosts listed in the 'host' 
attribute but denied entry into lab05 for example (not listed in any 
group 'host' attribute above) to the server.   If I have a new user 
that has joined that particular team at our organization, I can simply 
add her/him to the above groups and this user would get access only to 
the listed servers in 'host' attribute by default. I don't need to 
specify new groups in customized sssd.conf or ldap.conf files or in 
sshd config files.  Hence less to update with Salt or any other CM 
suite.  I've managed to setup SUDO rules and with the 
openssh-ldap.diff schema SSH public keys could be stored in AD as well 
and be read by OpenSSH.  So aside from the HBAC capability on groups, 
virtually all our needs are handled by the WS2012 AD DC as it has to 
follow the OpenLDAP standard anyway.  Now to get this we considered 
and are still considering FreeIPA.  However this idea poses a set of 
challenges:


1) In large organizations where the AD support department are only 
trained in Windows AD setup and configuration (Only windows guy's) 
this would require a minimal of 3 bodies to support that know 
LDAP/Linux.  This is a large cost.


2) The additional server requires the same hardening as the Windows AD 
DC servers meaning a new procedure has to be carved out for the 2+ 
FreeIPA servers to be supported, hardened and maintained (upgraded).


Now I probably sound somewhat anti-FreeIPA, however the challenges of 
implementing it in large organizations surface after some 
deliberation, so probably better to list then as it may help direct 
development of the product to contend with the challenges (Like having 
a document fully dedicated to hardening a FreeIPA server with selinux 
and other technologies in easy to maintain configuration).   I could 
be mistaken but some folks mention that it's 'better' to implement 
this sort of HBAC through other means (?? iptables ??) but never tried 
the alternatives yet.


So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to 
enable reading the 'host' attribute on AD/LDAP defined groups?

In FreeIPA we support HBAC rules for AD users and groups. What exactly
is wrong with that?

See 'ipa help trust' for details how to map AD groups to IPA groups and
then 'ipa help hbacrule' for how to limit access of those groups to
specific hosts and services on them.

This is all covered well in the guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html

--
/ Alexander Bokovoy

--
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] HBAC

[TomK]

Hey Guy's,

(Sending this again as I didn't have this email included in the 
freeipa-users mailing list so not sure if the other message will get 
posted.)


Before I post a ticket to RH Support for an RFE, I'll post the request 
here to get some feedback on options and what ideas folks have.  I've a 
situation as follows.  I have the following setup in WS 2012 AD DC:


TomK (user)
TomK Groups:
unixg
windowsg

unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'

TomK(user) also has the 'host' attribute defined as per the proper RFC 
for LDAP.  With SSSD rules I can define the rules to read the user 
'host' attribute but not the group 'host' attribute:



|access_provider = ldap ldap_access_order = host 
ldap_user_authorized_host = host|



Essentially TomK to be given access to hosts listed in the 'host' 
attribute but denied entry into lab05 for example (not listed in any 
group 'host' attribute above) to the server.   If I have a new user that 
has joined that particular team at our organization, I can simply add 
her/him to the above groups and this user would get access only to the 
listed servers in 'host' attribute by default. I don't need to specify 
new groups in customized sssd.conf or ldap.conf files or in sshd config 
files.  Hence less to update with Salt or any other CM suite.  I've 
managed to setup SUDO rules and with the openssh-ldap.diff schema SSH 
public keys could be stored in AD as well and be read by OpenSSH.  So 
aside from the HBAC capability on groups, virtually all our needs are 
handled by the WS2012 AD DC as it has to follow the OpenLDAP standard 
anyway.  Now to get this we considered and are still considering 
FreeIPA.  However this idea poses a set of challenges:


1) In large organizations where the AD support department are only 
trained in Windows AD setup and configuration (Only windows guy's) this 
would require a minimal of 3 bodies to support that know LDAP/Linux.  
This is a large cost.


2) The additional server requires the same hardening as the Windows AD 
DC servers meaning a new procedure has to be carved out for the 2+ 
FreeIPA servers to be supported, hardened and maintained (upgraded).


Now I probably sound somewhat anti-FreeIPA, however the challenges of 
implementing it in large organizations surface after some deliberation, 
so probably better to list then as it may help direct development of the 
product to contend with the challenges (Like having a document fully 
dedicated to hardening a FreeIPA server with selinux and other 
technologies in easy to maintain configuration).   I could be mistaken 
but some folks mention that it's 'better' to implement this sort of HBAC 
through other means (?? iptables ??) but never tried the alternatives yet.


So, cutting to the end, would it be possible to add an attribute like:

|ldap_user_authorized_host|

but perhaps called 'ldap_group_authorized_host' to the SSSD code to 
enable reading the 'host' attribute on AD/LDAP defined groups?


Cheers,
Tom



-- 
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] HBAC rules not applying to Solaris clients

[sipazzo]

Thanks Bob, I have tried to implement this and cannot seem to get it to work 
for me even though it seems straightforward. I tried both with using a 
user.allow file and adding the netgroup to /etc/passwd as well as moving lines 
around in the pam.conf and many different versions of pam.conf but it results 
in either everyone being able to login or no one being able to login. Do you 
mind sharing your pam.conf with me?
I have the following relevant entries in nsswitch.conf
passwd: files ldapgroup: files ldapshadow: files ldapnetgroup: ldap

 From: Bob 
 To: Natxo Asenjo  
Cc: Freeipa-users  
 Sent: Saturday, August 15, 2015 10:46 AM
 Subject: Re: [Freeipa-users] HBAC rules not applying to Solaris clients
   

For Solaris we are using the pam_list module to control which LDAP users can 
have system access. The pam_list module allow netgroups to be listed in a 
user.allow file. 

On Sat, Aug 15, 2015 at 1:05 PM, Natxo Asenjo  wrote:





On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden  wrote:

sipazzo wrote:


and my users are able to authenticate to the directory but the hbac
rules are not being applied. Any user whether given access or not can
login to the Solaris systems. The "allow-all" rule has been disabled, my
nsswitch.conf file looks good and I have tried different configs of
pam.d, including the provided example to try to resolve the issue. Am I
missing some steps?


HBAC enforcement is provided by sssd so doesn't work in Solaris.


one might try using solaris' RBAC system:

http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html

You would have to distribute your changes to all solaris systems.

There is a RBAC ldap schema 
http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for solaris, 
but I have never tried using it with freeipa. 

--
Groeten,
natxo
--
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



-- 
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

  -- 
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] HBAC rules not applying to Solaris clients

[sipazzo]

Ah I would love to help but have only been a Unix sysadmin for a couple years 
now (came from Windows side of house) and have little coding ability. Still 
happy to  help in any way I can though if you can find a place/need for me. You 
have all been very helpful to me so I would like to give back if I can.
   From: Jakub Hrozek 
 To: Martin Kosek  
Cc: Freeipa-users  
 Sent: Wednesday, August 19, 2015 12:23 AM
 Subject: Re: [Freeipa-users] HBAC rules not applying to Solaris clients
   
On Tue, Aug 18, 2015 at 09:05:14PM +0200, Martin Kosek wrote:
> On 08/15/2015 07:05 PM, Natxo Asenjo wrote:
> >
> >
> >On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden  ><mailto:rcrit...@redhat.com>> wrote:
> >
> >    sipazzo wrote:
> >
> >
> >        and my users are able to authenticate to the directory but the hbac
> >        rules are not being applied. Any user whether given access or not can
> >        login to the Solaris systems. The "allow-all" rule has been 
> >disabled, my
> >        nsswitch.conf file looks good and I have tried different configs of
> >        pam.d, including the provided example to try to resolve the issue. 
> >Am I
> >        missing some steps?
> >
> >
> >    HBAC enforcement is provided by sssd so doesn't work in Solaris.
> >
> >
> >one might try using solaris' RBAC system:
> >
> >http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html
> >
> >You would have to distribute your changes to all solaris systems.
> >
> >There is a RBAC ldap schema
> >http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for 
> >solaris,
> >but I have never tried using it with freeipa.
> >
> >--
> >Groeten,
> >natxo
> 
> Alternatively, you can also contribute to Jakub Hrozek's pam_hbac project:
> 
> https://github.com/jhrozek/pam_hbac

btw I have quite a few changes from the last weeks, so yes, I'm still
working on this, but the progress is slow, RHEL maintenance tends to eat
most time..



-- 
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


  -- 
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] HBAC rules not applying to Solaris clients

[Jakub Hrozek]

On Tue, Aug 18, 2015 at 09:05:14PM +0200, Martin Kosek wrote:
> On 08/15/2015 07:05 PM, Natxo Asenjo wrote:
> >
> >
> >On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden  >> wrote:
> >
> >sipazzo wrote:
> >
> >
> >and my users are able to authenticate to the directory but the hbac
> >rules are not being applied. Any user whether given access or not can
> >login to the Solaris systems. The "allow-all" rule has been 
> > disabled, my
> >nsswitch.conf file looks good and I have tried different configs of
> >pam.d, including the provided example to try to resolve the issue. 
> > Am I
> >missing some steps?
> >
> >
> >HBAC enforcement is provided by sssd so doesn't work in Solaris.
> >
> >
> >one might try using solaris' RBAC system:
> >
> >http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html
> >
> >You would have to distribute your changes to all solaris systems.
> >
> >There is a RBAC ldap schema
> >http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for 
> >solaris,
> >but I have never tried using it with freeipa.
> >
> >--
> >Groeten,
> >natxo
> 
> Alternatively, you can also contribute to Jakub Hrozek's pam_hbac project:
> 
> https://github.com/jhrozek/pam_hbac

btw I have quite a few changes from the last weeks, so yes, I'm still
working on this, but the progress is slow, RHEL maintenance tends to eat
most time..

-- 
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] HBAC rules not applying to Solaris clients

[Martin Kosek]

On 08/15/2015 07:05 PM, Natxo Asenjo wrote:



On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden mailto:rcrit...@redhat.com>> wrote:

sipazzo wrote:


and my users are able to authenticate to the directory but the hbac
rules are not being applied. Any user whether given access or not can
login to the Solaris systems. The "allow-all" rule has been disabled, my
nsswitch.conf file looks good and I have tried different configs of
pam.d, including the provided example to try to resolve the issue. Am I
missing some steps?


HBAC enforcement is provided by sssd so doesn't work in Solaris.


one might try using solaris' RBAC system:

http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html

You would have to distribute your changes to all solaris systems.

There is a RBAC ldap schema
http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for solaris,
but I have never tried using it with freeipa.

--
Groeten,
natxo


Alternatively, you can also contribute to Jakub Hrozek's pam_hbac project:

https://github.com/jhrozek/pam_hbac

:-)

Martin

--
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] HBAC rules not applying to Solaris clients

[sipazzo]

Ok thanks all. I will look into pam_list, integrating with the Solaris RBAC is 
probably beyond me as I am not that Solaris savvy and there is no documentation 
on using it with freeipa that I see.
I tried using AllowGroups in sshd_config on Solaris to restrict access but it 
only seems to work with primary group membership. Is this expected? From 
reading documentation it should work with secondary/supplementary documentation 
as well. Let me know if you have found a way around that please.
  From: Bob 
 To: Natxo Asenjo  
Cc: Freeipa-users  
 Sent: Saturday, August 15, 2015 10:46 AM
 Subject: Re: [Freeipa-users] HBAC rules not applying to Solaris clients
   

For Solaris we are using the pam_list module to control which LDAP users can 
have system access. The pam_list module allow netgroups to be listed in a 
user.allow file. 

On Sat, Aug 15, 2015 at 1:05 PM, Natxo Asenjo  wrote:





On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden  wrote:

sipazzo wrote:


and my users are able to authenticate to the directory but the hbac
rules are not being applied. Any user whether given access or not can
login to the Solaris systems. The "allow-all" rule has been disabled, my
nsswitch.conf file looks good and I have tried different configs of
pam.d, including the provided example to try to resolve the issue. Am I
missing some steps?


HBAC enforcement is provided by sssd so doesn't work in Solaris.


one might try using solaris' RBAC system:

http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html

You would have to distribute your changes to all solaris systems.

There is a RBAC ldap schema 
http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for solaris, 
but I have never tried using it with freeipa. 

--
Groeten,
natxo
--
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



-- 
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

   -- 
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] HBAC rules not applying to Solaris clients

[Bob]

For Solaris we are using the pam_list module to control which LDAP users
can have system access. The pam_list module allow netgroups to be listed in
a user.allow file.

On Sat, Aug 15, 2015 at 1:05 PM, Natxo Asenjo 
wrote:

>
>
> On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden 
> wrote:
>
>> sipazzo wrote:
>>
>>>
>>> and my users are able to authenticate to the directory but the hbac
>>> rules are not being applied. Any user whether given access or not can
>>> login to the Solaris systems. The "allow-all" rule has been disabled, my
>>> nsswitch.conf file looks good and I have tried different configs of
>>> pam.d, including the provided example to try to resolve the issue. Am I
>>> missing some steps?
>>>
>>
>> HBAC enforcement is provided by sssd so doesn't work in Solaris.
>>
>
> one might try using solaris' RBAC system:
>
>
> http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html
>
> You would have to distribute your changes to all solaris systems.
>
> There is a RBAC ldap schema
> http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for
> solaris, but I have never tried using it with freeipa.
>
> --
> Groeten,
> natxo
>
> --
> 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
>
-- 
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] HBAC rules not applying to Solaris clients

[Natxo Asenjo]

On Sat, Aug 15, 2015 at 5:24 PM, Rob Crittenden  wrote:

> sipazzo wrote:
>
>>
>> and my users are able to authenticate to the directory but the hbac
>> rules are not being applied. Any user whether given access or not can
>> login to the Solaris systems. The "allow-all" rule has been disabled, my
>> nsswitch.conf file looks good and I have tried different configs of
>> pam.d, including the provided example to try to resolve the issue. Am I
>> missing some steps?
>>
>
> HBAC enforcement is provided by sssd so doesn't work in Solaris.
>

one might try using solaris' RBAC system:

http://www.oracle.com/technetwork/systems/security/custom-roles-rbac-jsp-140865.html

You would have to distribute your changes to all solaris systems.

There is a RBAC ldap schema
http://docs.oracle.com/cd/E19455-01/806-5580/6jej518q5/index.html for
solaris, but I have never tried using it with freeipa.

--
Groeten,
natxo
-- 
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