[Freeipa-users] Contributing translations, modules (was Re: help)

[Timo Aaltonen]

On 02.11.2016 03:03, 郑磊 wrote:
> Hello Timo Aaltonen,
> I got your mail information from the changelog file of the freeipa
> deb package. I'm using freeipa on Ubuntu, and having a test and research
> with the function of freeipa. At the same time, I have carried on the
> chinese translation to the web interface, also added own log module in
> web interface, which can record our operation. However, For these
> changes I don't know how to interact with the organization or community.
> Whether I need to join an organization or community? Who should I
> contact with? Please help me. Thank you!

Hi, freeipa upstream would be your contact, you can try freeipa-users
first, here's how to contribute:

http://www.freeipa.org/page/Contribute

and here's where you can join the list:

https://www.redhat.com/mailman/listinfo/freeipa-users

I've CC'd this reply there.


-- 
t

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

[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] Service discovery and selection for IPA

[Jake]

Hey All, 
Quick question on IPA Service discover and selection (ldap/kerberos in ad 
trust). 

Do IPA clients ping results of SRV records to determine which server they send 
requests (for ldap/kerberos specifically)? 

I have 8 AD Domain controllers, 2 in each location, and 4 ipa servers (2 in 
each of 2 locations), it seems the ipa servers rarely choose the local ad 
controllers, is there a way to adjust this? Must I setup something like geo-dns 
with different service weights per subnet? 

Thanks! 
~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

[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] Allow external AD users on webui

[Jake]

Sorry for the late reply, I've seen this on the mailing list a few times and 
wondered it myselfthis was my solution:

IPA has an option to use RADIUS password, which you can also override the 
username.  So for those users that are allowed to manage IPA, we have 
google-auth and freeradius gateways setup with a user-override.

for example.
jev...@ipa.example.com has radius user of jev...@ad.example.com

I log into the webui with jev...@ipa.example.com with my password for 
jev...@ad.example.com (and in my case, I add my google auth OTP)

Does this help?
-Jake


- Original Message -
From: "Alexander Bokovoy" 
To: "Troels Hansen" 
Cc: "freeipa-users" 
Sent: Monday, October 31, 2016 3:59:36 AM
Subject: Re: [Freeipa-users] Allow external AD users on webui

On ma, 31 loka 2016, Troels Hansen wrote:
>- On Oct 31, 2016, at 8:33 AM, Alexander Bokovoy aboko...@redhat.com wrote:
>
>
>> You make it sound as if it is a done deal. It is not, there is a number
>> of changes that yet not figured out how to do in an efficient way.
>>
>> It is in our pipeline for 4.5. It is understandable that people ask for
>> this feature. It is also should be clear to you had it been a simple
>> thing, it would have been implemented already.
>>
>> If you want to see a progress, subscribe to the ticket.
>
>Hi Alexander
>
>It was in no way a critics of the FreeIPA team. I'm well aware of the
>work being out into this product from the core team, and appreciate
>every new release, but also not really able to help much with the
>development, only testing and feedback.
That's why I asked you to subscribe to the ticket. Once the changes will
be ready, you could help with testing them.

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

-- 
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] SSH as Root on CentOS 7 fails

[Sumit Bose]

On Mon, Oct 31, 2016 at 04:17:08PM -0400, Geordie Grindle wrote:
> 
> Hello,
> 
> I’m unable to ssh as ‘root’ onto any of my new CentOS 7 hosts. I’ve always 
> been able to do so on CentOS6.x
> 
> We normally have the file ‘/root/.k5login’ listing the designated system 
> admins’ principals. Once on a CentOS 7, an admin can ‘ksu’ and become root as 
> we expected.
> 
> We are using puppet and Foreman to build our hosts so they are in every way 
> we can think of, identical, except for the O/s version.
> 
> I’ve confirmed forward and reverse DNS and that the ‘kvno’ number matches 
> what’s reported by ‘klist -k’. 
> 
> I enabled "LogLevel DEBUG” in sshd_config and restarted sshd on a CentOS7 
> host: 
> 
> Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user 
> testuser service ssh-connection method none [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 0 failures 0 [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: initializing for 
> "testuser"
> Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_RHOST to 
> "someserver.test.com"
> Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_TTY to "ssh"
> Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user 
> testuser service ssh-connection method gssapi-with-mic [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 1 failures 0 [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: Postponed gssapi-with-mic for 
> testuser from 10.0.0.55 port 36383 ssh2 [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: Received some client 
> credentials
> Oct 31 19:22:36 someserver sshd[12378]: Authorized to testuser, krb5 
> principal testu...@test.com (ssh_gssapi_krb5_cmdok)
> 
> 
> 
> Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user 
> root service ssh-connection method none [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 0 failures 0 [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: initializing for "root"
> Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_RHOST to 
> "someserver.test.com"
> Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_TTY to "ssh"
> Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user 
> root service ssh-connection method gssapi-with-mic [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 1 failures 0 [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: Postponed gssapi-with-mic for root 
> from 10.0.0.55 port 36384 ssh2 [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: Received some client 
> credentials
> Oct 31 19:35:42 someserver sshd[12409]: Failed gssapi-with-mic for root from 
> 10.0.0.55 port 36384 ssh2
> ...
> Oct 31 19:35:42 someserver sshd[12577]: debug1: userauth-request for user 
> root service ssh-connection method gssapi-with-mic [preauth]
> Oct 31 19:35:42 someserver sshd[12577]: debug1: attempt 4 failures 1 [preauth]
> 
> Appreciate any thoughts or suggestions you have.

Which version of SSSD are you using. SSSD provides a localauth plugin to
make matching the Kerberos principal and the provided login name more
easy. It creates a configuration snippet for krb5.conf in
/var/lib/sss/pubconf/krb5.include.d/localauth_plugin and the content
should typically look like

[plugins]
 localauth = {
  module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so
 }


Some versions of SSSD added a 'enable_only = sssd' line which disables
the .k5login checks. If you have this line in the localauth_plugin file
I would recommend to check if a newer version of SSSD is available for
your platform which do not create the line. As an alternative you can
just remove the line from the file. But since SSSD will recreate the
file at startup you should make it immutable with chattr and the 'i'
option.

HTH

bye,
Sumit

> 
> Yours,
> Geordie Grindle
> 
> 
> -- 
> 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