date:20160713

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

2016-07-13 Thread Jan Pazdziora

On Mon, Jul 11, 2016 at 07:00:04PM -0700, Harry Kashouli wrote:
> 
> I have a freeipa server set up, and would like to access the Web UI
> remotely (from outside my home network).
> 
> I set up a fresh Fedora 24 server install, and installed freeipa-server.
>  - I own a domain, domain.com
>  - The hostname of my freeipa server is hostname.subdomain.domain.com
>  - My home network domain is subdomain.domain.com
> 
> I set up a CNAME hostname.domain.com and port forwardings, and I tested
> this works with nginx on the same machine; I can successfully see the nginx
> test page.
> I then assumed I could do the same with the freeipa Web UI, but when I
> navigate to http://hostname.domain.com:, it switches to
> https://hostname.subdomain.domain.com:, and with the
> following error: "Server not found"
> 
> What am I doing wrong?

There are some more config tweaks likely needed.

Writeup

https://www.adelton.com/freeipa/freeipa-behind-proxy-with-different-name

should help you resolve the issue.

-- 
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] FreeIPA (Add Replica fails on GSSAPI)

2016-07-13 Thread Bjarne Blichfeldt

Well, I just had the same problem, but in my case I also tried to install a ca:
“ipa-replica-install --setup-ca …..”

Without “--set-up”  the installation succeeded.

Regards,
Bjarne



From: Devin Acosta [mailto:linuxguru...@gmail.com]
Sent: 12. juli 2016 21:35
To: freeipa-users@redhat.com
Subject: [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)

I am trying to add a 4th replica to my FreeIPA installation. I am running the 
latest CentOS 7.2 (full updates) and i have tried multiple times and fails 
every time in same location. When it fails I remove the replication agreements 
and try again and keeps failing in same location.


[root@ipa03-aws centos]# ipa-replica-install 
replica-info-ipa03-aws.rsinc.local.gpg
WARNING: conflicting time synchronization service 'chronyd' will
be disabled in favor of ntpd

Directory Manager (existing master) password:

Run connection check to master
Check connection from replica to remote master 'ipa01-aws.rsinc.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

The following list of ports use UDP protocol and would need to be
checked manually:
   Kerberos KDC: UDP (88): SKIPPED
   Kerberos Kpasswd: UDP (464): SKIPPED

Connection from replica to master is OK.
Start listening on required ports for remote master check
Get credentials to log in to remote master
admin@RSINC.LOCAL password:

Check SSH connection to remote master
Execute check on remote master
Check connection from master to remote replica 'ipa03-aws.rsinc.local':
   Directory Service: Unsecure port (389): OK
   Directory Service: Secure port (636): OK
   Kerberos KDC: TCP (88): OK
   Kerberos KDC: UDP (88): OK
   Kerberos Kpasswd: TCP (464): OK
   Kerberos Kpasswd: UDP (464): OK
   HTTP Server: Unsecure port (80): OK
   HTTP Server: Secure port (443): OK

Connection from master to replica is OK.

Connection check OK
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated time: 1 minute
  [1/38]: creating directory server user
  [2/38]: creating directory server instance
  [3/38]: adding default schema
  [4/38]: enabling memberof plugin
  [5/38]: enabling winsync plugin
  [6/38]: configuring replication version plugin
  [7/38]: enabling IPA enrollment plugin
  [8/38]: enabling ldapi
  [9/38]: configuring uniqueness plugin
  [10/38]: configuring uuid plugin
  [11/38]: configuring modrdn plugin
  [12/38]: configuring DNS plugin
  [13/38]: enabling entryUSN plugin
  [14/38]: configuring lockout plugin
  [15/38]: creating indices
  [16/38]: enabling referential integrity plugin
  [17/38]: configuring ssl for ds instance
  [18/38]: configuring certmap.conf
  [19/38]: configure autobind for root
  [20/38]: configure new location for managed entries
  [21/38]: configure dirsrv ccache
  [22/38]: enable SASL mapping fallback
  [23/38]: restarting directory server
  [24/38]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 4 seconds elapsed
Update succeeded

  [25/38]: updating schema
  [26/38]: setting Auto Member configuration
  [27/38]: enabling S4U2Proxy delegation
  [28/38]: importing CA certificates from LDAP
  [29/38]: initializing group membership
  [30/38]: adding master entry
  [31/38]: initializing domain level
  [32/38]: configuring Posix uid/gid generation
  [33/38]: adding replication acis
  [34/38]: enabling compatibility plugin
  [35/38]: activating sidgen plugin
  [36/38]: activating extdom plugin
  [37/38]: tuning directory server
  [38/38]: configuring directory to start on boot
Done configuring directory server (dirsrv).
Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds
  [1/8]: adding sasl mappings to the directory
  [2/8]: configuring KDC
  [3/8]: creating a keytab for the directory
  [4/8]: creating a keytab for the machine
  [5/8]: adding the password extension to the directory
  [6/8]: enable GSSAPI for replication
  [error] RuntimeError: One of the ldap service principals is missing. 
Replication agreement cannot be converted.
Replication error message: Can't acquire busy replica
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.

ipa.ipapython.install.cli.install_tool(Replica): ERROROne of the ldap 
service principals is missing. Replication agreement cannot be converted.
Replication error message: Can't acquire busy replica

Please see attached file for the full log file.

Any help would be appreciated!

-- 
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] Deny bind for external LDAP if password is expired

2016-07-13 Thread Prashant Bapat

Tough luck! If its tricky for you (FreeIPA core developers) then its pretty
much impossible to solve it for mere mortals like me !

On 11 July 2016 at 19:43, Rob Crittenden  wrote:

> Prashant Bapat wrote:
>
>> I cherrypicked the commit id 3b7d5e7543a074d7d24556cadc6c95be9871cfc6
>> and compiled the ipa-pwd-extop slapi plugin.
>>
>> Now the user is denied bind. But unable to reset the password.
>>
>
> Right, it's a tricky problem which is why it hasn't been resolved yet. You
> have come full circle through the same steps we went through.
>
> rob
>
>
>>
>> On 8 July 2016 at 13:21, Martin Kosek > > wrote:
>>
>> On 07/07/2016 05:19 PM, Prashant Bapat wrote:
>> > Anyone ?!
>> >
>> > On 6 July 2016 at 22:36, Prashant Bapat > 
>> > >> wrote:
>> >
>> > Hi,
>> >
>> > We are using FreeIPA's LDAP as the base for user authentication
>> in a
>> > different application. So far I have created a sysaccount which
>> does the
>> > lookup etc for a user and things are working as expected. I'm
>> even able to
>> > use OTP from the external app.
>> >
>> > One problem I'm struggling to fix is the expired passwords. Is
>> there a way
>> > to deny bind to LDAP only from this application? Obviously the
>> user would
>> > need to go to IPA's web UI and reset his password there.
>> >
>> > I came across this tickethttps://
>> fedorahosted.org/freeipa/ticket/1539 but
>> > looks like this is an old one.
>> >
>> > Thanks.
>> > --Prashant
>>
>> Hello Prashant,
>>
>> https://fedorahosted.org/freeipa/ticket/1539 seems to be the right
>> ticket, if
>> you want users with expired passwords to be denied, but it was not
>> implemented
>> yet. Help welcome!
>>
>> As a workaround, I assume you could simply leverage Kerberos for
>> authentication
>> - it does respect expired passwords. We have advise on how to
>> integrate that to
>> external web applications here:
>>
>> http://www.freeipa.org/page/Web_App_Authentication
>>
>> 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 and AD users

2016-07-13 Thread 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
>> > >>

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

2016-07-13 Thread Harry Kashouli

Thanks for all the info. I think I sorted out the rewrite rules now, and
the error I get is "Secure Connection Failed.
SSL_ERROR_UNRECOGNIZED_NAME_ALERT".

I'm going to try and google this, since I'm assuming I need a ServerAlias
somewhere. If someone knows the correct way, please let me know :)

-Harry

On 13 July 2016 at 08:11, Rob Crittenden  wrote:

> Harry Kashouli wrote:
>
>> I tried uncommenting everything in the ipa-rewrite.conf file, but it
>> still changed the web address. I'll try clearing the cache, in case that
>> was still remembering the links.
>>
>> I may be attacking my original thought badly, if this is going to be bad
>> for security. I'm wanting to allow users to change their passwords
>> remotely, so I figured giving them public access to the Web UI was the
>> way to go. Is there a better solution?
>>
>
> Moving back to list.
>
> Getting the rewrite rules right can be tricky sometimes. You might have an
> easier time using a proxy instead. Exposing the UI increases the attack
> surface area so as usual it's a balance of security and convenience that
> you need to assess.
>
> A community portal was started last summer but has largely stalled. This
> is the long-term plan for what you're looking for. The design and a pointer
> to the current code is at https://www.freeipa.org/page/V4/Community_Portal
>
> rob
>
>
>> -Harry
>>
>> On 11 July 2016 at 19:56, Rob Crittenden > > wrote:
>>
>> Harry Kashouli wrote:
>>
>> Hi all,
>>
>> I have a freeipa server set up, and would like to access the Web
>> UI
>> remotely (from outside my home network).
>>
>> I set up a fresh Fedora 24 server install, and installed
>> freeipa-server.
>>- I own a domain, domain.com 
>> 
>>- The hostname of my freeipa server is
>> hostname.subdomain.domain.com <
>> http://hostname.subdomain.domain.com>
>> 
>>- My home network domain is subdomain.domain.com
>> 
>> 
>>
>> I set up a CNAME hostname.domain.com
>>   and
>> port forwardings, and I tested this works with nginx on the same
>> machine; I can successfully see the nginx test page.
>> I then assumed I could do the same with the freeipa Web UI, but
>> when I
>> navigate to http://hostname.domain.com:, it
>> switches to
>> https://hostname.subdomain.domain.com:, and with
>> the
>> following error: "Server not found"
>>
>> What am I doing wrong?
>>
>>
>> Look at ipa-rewrite.conf in the IPA Apache config. It does rewriting
>> to the real name of the IPA server when it was installed. You can
>> try tweaking this to allow both names, or to just not do the
>> rewriting.
>>
>> You may have issues with Kerberos and SSL due to using a different
>> name.
>>
>> You definitely don't want to use IPA over an unsecure channel.
>>
>> rob
>>
>>
>>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] named-pkcs11 fails to start on new replica

2016-07-13 Thread Bob Hinton

Hi,

We are trying to create a new replica on RHEL 7.2

This completes but named-pkcs11 fails to start -

 systemctl status named-pkcs11.service
● named-pkcs11.service - Berkeley Internet Name Domain (DNS) with native
PKCS#11
   Loaded: loaded (/usr/lib/systemd/system/named-pkcs11.service;
disabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-07-13 18:38:15 BST;
51min ago
  Process: 25913 ExecStart=/usr/sbin/named-pkcs11 -u named $OPTIONS
(code=exited, status=1/FAILURE)
  Process: 25910 ExecStartPre=/bin/bash -c if [ !
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z
/etc/named.conf; else echo "Checking of zone files is disabled"; fi
(code=exited, status=0/SUCCESS)

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: corporation. 
Support and training for BIND 9 are
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: available at
https://www.isc.org/support
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]:

Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: adjusted limit on
open files from 4096 to 1048576
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: found 1 CPU,
using 1 worker thread
Jul 13 18:38:15 ipa001.mgmt.local named-pkcs11[25916]: using 1 UDP
listener per interface
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service:
control process exited, code=exited status=1
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Failed to start Berkeley
Internet Name Domain (DNS) with native PKCS#11.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: Unit named-pkcs11.service
entered failed state.
Jul 13 18:38:15 ipa001.mgmt.local systemd[1]: named-pkcs11.service failed.

# /usr/sbin/named-pkcs11 -d 9 -g
13-Jul-2016 19:31:01.283 starting BIND 9.9.4-RedHat-9.9.4-29.el7_2.1 -d 9 -g
13-Jul-2016 19:31:01.283 built with '--build=x86_64-redhat-linux-gnu'
'--host=x86_64-redhat-linux-gnu' '--program-prefix='
'--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64'
'--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
'--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool'
'--localstatedir=/var' '--enable-threads' '--enable-ipv6'
'--enable-filter-' '--enable-rrl' '--with-pic' '--disable-static'
'--disable-openssl-version-check' '--enable-exportlib'
'--with-export-libdir=/usr/lib64'
'--with-export-includedir=/usr/include'
'--includedir=/usr/include/bind9' '--enable-native-pkcs11'
'--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes'
'--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
'--with-dlz-filesystem=yes' '--with-dlz-bdb=yes' '--with-gssapi=yes'
'--disable-isc-spnego' '--enable-fixed-rrset'
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
'build_alias=x86_64-redhat-linux-gnu'
'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'
'LDFLAGS=-Wl,-z,relro ' 'CPPFLAGS= -DDIG_SIGCHASE'
13-Jul-2016 19:31:01.283

13-Jul-2016 19:31:01.284 BIND 9 is maintained by Internet Systems
Consortium,
13-Jul-2016 19:31:01.284 Inc. (ISC), a non-profit 501(c)(3) public-benefit
13-Jul-2016 19:31:01.284 corporation.  Support and training for BIND 9 are
13-Jul-2016 19:31:01.284 available at https://www.isc.org/support
13-Jul-2016 19:31:01.284

13-Jul-2016 19:31:01.284 adjusted limit on open files from 4096 to 1048576
13-Jul-2016 19:31:01.284 found 1 CPU, using 1 worker thread
13-Jul-2016 19:31:01.284 using 1 UDP listener per interface
13-Jul-2016 19:31:01.284 using up to 4096 sockets
13-Jul-2016 19:31:01.284 Registering DLZ_dlopen driver
13-Jul-2016 19:31:01.284 Registering SDLZ driver 'dlopen'
13-Jul-2016 19:31:01.284 Registering DLZ driver 'dlopen'
13-Jul-2016 19:31:01.287 initializing DST: PKCS#11 initialization failed
13-Jul-2016 19:31:01.287 exiting (due to fatal error)

# tail -2 /var/log

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]:
ObjectStore.cpp(59): Failed to enumerate object store in
/var/lib/softhsm/tokens/

Jul 13 19:31:01 ipa001.mgmt.local named-pkcs11[27088]: SoftHSM.cpp(456):
Could not load the object store

I've tried "ipa-server-upgrade" and

mv /var/lib/ipa/dnssec/tokens /var/lib/ipa/dnssec/tokens-OLD

ipa-dns-install

But I haven't managed to fix it.

Using "ipactl start -f" means the rest of the ipa services seem to work
properly, but without named.

Is there a way to fix the named issue or is it much simpler to
disconnect the replica, uninstall it and start again ?

Thanks

Bob Hinton

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-13 Thread Sullivan, Daniel [AAA]

Jakub, Justin,

Thank you both very much for taking the time to continue helping me resolve 
this issue.  I apologize for not replying right away; I’ve been dealing with a 
production issue for most of the morning.

An invocation of ‘id 
a.cri.dsulli...@bsdad.uchicago.edu’ 
on the IPA DC shows me as a member of the POSIX IPA group 
(cri_server_administrators_...@ipa.cri.uchicago.edu)
 as well as the AD domain group in the trusted domain 
(cri-aaa_server_administrat...@bsdad.uchicago.edu).
  This remains consistent across any number of successful sshd logins into the 
DC using my 
a.cri.dsullivan@bsdad.uchicago.edu 
account, including after clearing the cache on the DC.

On the client, I am seeing some unusual behavior.  If I run the commands 
'sss_cache -E; service sssd stop ; rm -rf /var/log/sssd/* ; service sssd start’ 
, then run ‘id 
a.cri.dsulli...@bsdad.uchicago.edu’, 
I see the POSIX IPA group as well as the AD domain group as described above 
(what I presumably want and expect).  However (and this is the unusual part), 
if I attempt to login via SSH (it will fail with HBAC validation), and then run 
the ‘id 
a.cri.dsulli...@bsdad.uchicago.edu’ 
command again , the POSIX IPA group disappears from the list of groups output 
by the id command.  From what I can tell, this group will not reappear in the 
group list on the client until the client cache is cleared.  Presumably this 
behavior is related to the HBAC authentication errors I am experiencing.  I 
have cleared the cache on both the DC and the client using ssh_cache -E and 
this behavior is still exhibited.  With respect to output from testing:

1) The sssd domain log from from the client of the initial id invocation (both 
groups appear) after clearing the cache (on the client) can be found here (this 
output contains both groups): 
https://gist.github.com/dsulli99/7117f8d567cc7cdf727d474b0aeab8da
2) The sssd domain log from the client for the failed sshd login (similar to 
the output I provided yesterday, however re-captured) can be found here (after 
this operation the IPA group disappears from the list of groups from the id 
command): 
https://gist.github.com/dsulli99/668a8799709ff0cd311b321206591124
3) The DC log (after the client cache is cleared) of my running the id 
invocation (from the client) can be found here (this is the DC side of 1) from 
above. https://gist.github.com/dsulli99/a2a5e80b6a8b143afa20024aa40a7b39
4) The DC log of the the failed sshd login into the client (this is the DC side 
of 2) from above is 
https://gist.github.com/dsulli99/4e3ba53c942ad78d7487ae51da92007e

I really appreciate your help with looking at this issue.  As I said I have 
another machine built from the same image that this is working fine on.  I am 
going to keep plugging away at this, I will let you know if I come up with 
anything.

Dan




This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


-- 
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] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-13 Thread Sullivan, Daniel [AAA]

Hi, Lachlan,

Yes, I see that from here 
(https://www.redhat.com/archives/freeipa-users/2016-May/msg00322.html).  
Unfortunately clearing the cache and restarting SSSD is not proving to help us. 
 I’d be interested to know any progress you make on this issue.

Thank you for responding to me.

Best,

Dan Sullivan

On Jul 12, 2016, at 8:04 PM, Lachlan Musicman 
> wrote:

This is exactly the issue I'm seeing too, various differences, but the symptoms 
are the same.

Main diff would be that sometimes stopping sssd, clearing cache and restarting 
sssd works, but only if individual AD domain members are added to the external 
group - not AD domain groups.

Cheers
L.

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

- Grace Hopper

On 13 July 2016 at 08:07, Sullivan, Daniel [AAA] 
> wrote:
Justin,

I really appreciate you taking the time to respond to me.  This problem is 
driving me crazy and I will certainly take any help I can get. My suspicion is 
that the external user group in the policy below was causing the log entry you 
specified, removing it from the policy does not remediate the problem, even 
after flushing the client cache.

The way I have this setup is as follows:

1) I created a POSIX group in IPA named 
'cri-cri_server_administrators_ipa’
 and allowed IPA to assign the GID.
2) I created an external group in IPA named 
'cri-cri_server_administrators_external’
 and added the AD group in the trusted domain as an external member to this 
group 
(cri-cri_server_administrat...@bsdad.uchicago.edu>).
3) I added the group 
cri-cri_server_administrators_external
 as a member of 
'cri-cri_server_administrators_ipa’

The HBAC rule is configured as (removing the external group does not seem to 
make a difference).

[root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
'cri-cri_server_administrators_allow_all'
  Rule name: cri-cri_server_administrators_allow_all
  Host category: all
  Service category: all
  Description: Allow anyone in 
cri-cri_server_administrat...@bsdad.uchicago.edu>
 to login to any machine
  Enabled: TRUE
  User Groups: cri-cri_server_administrators_external, 
cri-cri_server_administrators_ipa
[root@cri-ksysipadcp2 a.cri.dsullivan]#

For example, the problem still persists when the policy is configured in this 
manner:

[root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
'cri-cri_server_administrators_allow_all'
  Rule name: cri-cri_server_administrators_allow_all
  Host category: all
  Service category: all
  Description: Allow anyone in 
cri-cri_server_administrat...@bsdad.uchicago.edu>
 to login to any machine
  Enabled: TRUE
  User Groups: cri-cri_server_administrators_ipa

And my login validates against the host in question as follows:

As I said I have this working consistently (i.e. can flush the cash) on another 
host with the same exact version of IPA and SSSD.  Here is a validation of 
hbactest (works with either of the two policy configurations above).

[root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbactest
User name: 
a.cri.dsulli...@bsdad.uchicago.edu>
Target host: 
cri-kcriwebgdp1.cri.uchicago.edu>
Service: sshd

Access granted: True

  Matched rules: cri-cri_server_administrators_allow_all
  Not matched rules: cri-hpc_server_administration
  Not matched rules: Gardner_cluster_login_no_ssh
  Not matched rules: s.cri.ipa-idprovisioner_domain_controllers
[root@cri-ksysipadcp2 a.cri.dsullivan]#

Thank you again for your response.

Best,

Dan

On Jul 12, 2016, at 4:12 PM, Justin Stephenson 
>>
 wrote:

Hello,

I am assuming this is the AD trust user that is having the problem with HBAC, 
in my

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-13 Thread Sullivan, Daniel [AAA]

Sumit,

Thank you for getting back to me  I really appreciate you taking the time to 
help me assess this problem (I am not authorized to view this bug).  In order 
to test I upgraded to ipa-server 4.2.0-15.el7_2.17 and flushed the cache on 
both the client and the server; the problem still presents itself. 

I’ve seen some threads around that seem related to what I am experiencing, i.e. 

https://www.redhat.com/archives/freeipa-users/2016-May/msg00354.html

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

Based on my reading I think that the version of the server I upgraded to would 
have fixed this problem, though (it did not).

Dan Sullivan

> On Jul 13, 2016, at 3:20 AM, Sumit Bose  wrote:
> 
> On Wed, Jul 13, 2016 at 08:37:44AM +0200, Jakub Hrozek wrote:
>> On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
>>> On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] wrote:
 Justin,

 I really appreciate you taking the time to respond to me.  This problem
 is driving me crazy and I will certainly take any help I can get. My
 suspicion is that the external user group in the policy below was
 causing the log entry you specified, removing it from the policy does
 not remediate the problem, even after flushing the client cache.

 The way I have this setup is as follows:

 1) I created a POSIX group in IPA named
 'cri-cri_server_administrators_ipa' and allowed IPA to assign the GID.
 2) I created an external group in IPA named
 'cri-cri_server_administrators_external’ and added the AD group in the
 trusted domain as an external member to this group
 (cri-cri_server_administrat...@bsdad.uchicago.edu).
 3) I added the group cri-cri_server_administrators_external' as a
 member of 'cri-cri_server_administrators_ipa’

 The HBAC rule is configured as (removing the external group does not
 seem to make a difference).

 [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
 'cri-cri_server_administrators_allow_all'
 Rule name: cri-cri_server_administrators_allow_all
 Host category: all
 Service category: all
 Description: Allow anyone in 
 cri-cri_server_administrat...@bsdad.uchicago.edu
  to login to any machine
 Enabled: TRUE
 User Groups: cri-cri_server_administrators_external, 
 cri-cri_server_administrators_ipa
 [root@cri-ksysipadcp2 a.cri.dsullivan]#

 For example, the problem still persists when the policy is configured in 
 this manner:

 [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
 'cri-cri_server_administrators_allow_all'
 Rule name: cri-cri_server_administrators_allow_all
 Host category: all
 Service category: all
 Description: Allow anyone in 
 cri-cri_server_administrat...@bsdad.uchicago.edu to login to any machine
 Enabled: TRUE
 User Groups: cri-cri_server_administrators_ipa

 And my login validates against the host in question as follows:

 As I said I have this working consistently (i.e. can flush the cash) on
 another host with the same exact version of IPA and SSSD.  Here is a
 validation of hbactest (works with either of the two policy
 configurations above).
>>> I think you problems are related to this snippet of your domain log
>>> where SSSD on IPA client was unable to add membership of your user to
>>> any of these groups:
>>> 
> 
> ...
> 
>>> 
>>> as result, the user is viewed by SSSD on this IPA client as not
>>> belonging to the cri-cri_server_administrat...@bsdad.uchicago.edu group
>>> and thus, HBAC rule validation on this client fails.
>> 
>> First, we have some debug messages in this part of sssd that can really
>> use some improvement. That is, some debug messages are expected to
>> report failures and we recover from them later.
>> 
>> But in general Alexander is right. Does 'id
>> a.cri.dsulli...@bsdad.uchicago.edu' report the user as a member of the
>> group that should be allowing access?
>> 
>> If not, I would suggest to run:
>>1) sss_cache -E on both server and client (don't remove the cache,
>>please)
>>2) truncate the logs on server and client
>>3) run id a.cri.dsulli...@bsdad.uchicago.edu on the client
>> then send us the logs from that single id run..
> 
> If some of the IPA group memberships are missing you might hit
> https://bugzilla.redhat.com/show_bug.cgi?id=1304333 which is not fixed
> in the IPA version you use (ipa-4.2.0-15.el7_2.6.1).
> 
> Mabye upgrading the server helps?
> 
> 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

This e-mail is intended only for the use of the

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

2016-07-13 Thread Christophe TREFOIS

Hi Rob,

On that note, how do you handle password changes / first time logins for users 
that are external to the organization?

We need to create accounts for external partners, and expose the UI to the 
outside so that people can login and change their passwords / add their SSH 
keys.

However, I’m worried about security. Is there any recommendations there on how 
to do this?
Is FreeIPA actually safe enough to do this?

Kind regards,

—
Christophe  

> On 13 Jul 2016, at 17:11, Rob Crittenden  wrote:
> 
> Harry Kashouli wrote:
>> I tried uncommenting everything in the ipa-rewrite.conf file, but it
>> still changed the web address. I'll try clearing the cache, in case that
>> was still remembering the links.
>> 
>> I may be attacking my original thought badly, if this is going to be bad
>> for security. I'm wanting to allow users to change their passwords
>> remotely, so I figured giving them public access to the Web UI was the
>> way to go. Is there a better solution?
> 
> Moving back to list.
> 
> Getting the rewrite rules right can be tricky sometimes. You might have an 
> easier time using a proxy instead. Exposing the UI increases the attack 
> surface area so as usual it's a balance of security and convenience that you 
> need to assess.
> 
> A community portal was started last summer but has largely stalled. This is 
> the long-term plan for what you're looking for. The design and a pointer to 
> the current code is at https://www.freeipa.org/page/V4/Community_Portal
> 
> rob
> 
>> 
>> -Harry
>> 
>> On 11 July 2016 at 19:56, Rob Crittenden > > wrote:
>> 
>>Harry Kashouli wrote:
>> 
>>Hi all,
>> 
>>I have a freeipa server set up, and would like to access the Web UI
>>remotely (from outside my home network).
>> 
>>I set up a fresh Fedora 24 server install, and installed
>>freeipa-server.
>>   - I own a domain, domain.com 
>>
>>   - The hostname of my freeipa server is
>>hostname.subdomain.domain.com 
>>
>>   - My home network domain is subdomain.domain.com
>>
>>
>> 
>>I set up a CNAME hostname.domain.com
>>  and
>>port forwardings, and I tested this works with nginx on the same
>>machine; I can successfully see the nginx test page.
>>I then assumed I could do the same with the freeipa Web UI, but
>>when I
>>navigate to http://hostname.domain.com:, it
>>switches to
>>https://hostname.subdomain.domain.com:, and with the
>>following error: "Server not found"
>> 
>>What am I doing wrong?
>> 
>> 
>>Look at ipa-rewrite.conf in the IPA Apache config. It does rewriting
>>to the real name of the IPA server when it was installed. You can
>>try tweaking this to allow both names, or to just not do the rewriting.
>> 
>>You may have issues with Kerberos and SSL due to using a different name.
>> 
>>You definitely don't want to use IPA over an unsecure channel.
>> 
>>rob
>> 
>> 
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project


-- 
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] Web UI access from outside the home network via port forwarding

2016-07-13 Thread Rob Crittenden


Harry Kashouli wrote:

I tried uncommenting everything in the ipa-rewrite.conf file, but it
still changed the web address. I'll try clearing the cache, in case that
was still remembering the links.

I may be attacking my original thought badly, if this is going to be bad
for security. I'm wanting to allow users to change their passwords
remotely, so I figured giving them public access to the Web UI was the
way to go. Is there a better solution?


Moving back to list.

Getting the rewrite rules right can be tricky sometimes. You might have 
an easier time using a proxy instead. Exposing the UI increases the 
attack surface area so as usual it's a balance of security and 
convenience that you need to assess.


A community portal was started last summer but has largely stalled. This 
is the long-term plan for what you're looking for. The design and a 
pointer to the current code is at 
https://www.freeipa.org/page/V4/Community_Portal


rob



-Harry

On 11 July 2016 at 19:56, Rob Crittenden > wrote:

Harry Kashouli wrote:

Hi all,

I have a freeipa server set up, and would like to access the Web UI
remotely (from outside my home network).

I set up a fresh Fedora 24 server install, and installed
freeipa-server.
   - I own a domain, domain.com 

   - The hostname of my freeipa server is
hostname.subdomain.domain.com 

   - My home network domain is subdomain.domain.com



I set up a CNAME hostname.domain.com
  and
port forwardings, and I tested this works with nginx on the same
machine; I can successfully see the nginx test page.
I then assumed I could do the same with the freeipa Web UI, but
when I
navigate to http://hostname.domain.com:, it
switches to
https://hostname.subdomain.domain.com:, and with the
following error: "Server not found"

What am I doing wrong?


Look at ipa-rewrite.conf in the IPA Apache config. It does rewriting
to the real name of the IPA server when it was installed. You can
try tweaking this to allow both names, or to just not do the rewriting.

You may have issues with Kerberos and SSL due to using a different name.

You definitely don't want to use IPA over an unsecure channel.

rob




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

Re: [Freeipa-users] (DRAFT) HA mail services with FreeIPA, postfix, dovecot, amavisd-new, clamd and PLAIN/GSSAPI SSO

2016-07-13 Thread Rob Crittenden


Günther J. Niederwimmer wrote:

Hello,

some days ago I found this doc, now I like to setup a secure mail server but
the article is now missing?

Can this come back?

Thanks,



This is on the freeipa.org wiki which would have been nice to mention.

It isn't exactly missing but the contents are gone. The author is the 
one who wiped it so there very well could be a good reason (like it 
doesn't work).


From my reading of the history it looks like it changed April 12, not a 
few days ago.


You can see the original page at 
http://www.freeipa.org/index.php?title=(DRAFT)_HA_mail_services_with_FreeIPA,_postfix,_dovecot,_amavisd-new,_clamd_and_PLAIN/GSSAPI_SSO=12296


rob

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

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Danila Ladner

Update to this one:
It has been running smoothly on 6.5

[root@dev-zlei.sec1 ~]# cat /etc/redhat-release
CentOS release 6.5 (Final)

[root@dev-zlei.sec1 ~]# rpm -qa | grep sssd
sssd-client-1.12.4-47.el6.x86_64
sssd-ldap-1.12.4-47.el6.x86_64
sssd-ad-1.12.4-47.el6.x86_64
python-sssdconfig-1.12.4-47.el6.noarch
sssd-common-1.12.4-47.el6.x86_64
sssd-proxy-1.12.4-47.el6.x86_64
sssd-common-pac-1.12.4-47.el6.x86_64
sssd-krb5-1.12.4-47.el6.x86_64
sssd-ipa-1.12.4-47.el6.x86_64
sssd-krb5-common-1.12.4-47.el6.x86_64
sssd-1.12.4-47.el6.x86_64

On Wed, Jul 13, 2016 at 9:56 AM, Tomas Simecek 
wrote:

> Thanks,
> I will try. But I am afraid to update to more recent version then those in
> official repos.
>
> Thanks anyway.
>
> T.
>
> 2016-07-13 15:39 GMT+02:00 :
>
>> Update to at least 1.12 sssd and libsss_sudo. As I recall sudo ipa
>> provider did not work under 1.11
>>
>> Sent from my iPhone
>>
>> On Jul 13, 2016, at 9:02 AM, Tomas Simecek 
>> wrote:
>>
>> Hi,
>> versions are:
>> sssd-client-1.11.6-30.el6.x86_64
>> sssd-ipa-1.11.6-30.el6.x86_64
>> ipa-client-3.0.0-50.el6.centos.1.x86_64
>> as part of:
>> CentOS release 6.6 (Final)
>>
>> T.
>>
>> 2016-07-13 14:52 GMT+02:00 :
>>
>>> Again what is client version on 6.5?
>>>
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 13, 2016, at 8:25 AM, Tomas Simecek 
>>> wrote:
>>>
>>> Thanks for your information Lukas,
>>> I have changed sudo_provider to ipa, restarted sssd and no difference.
>>> Logfile still says "Access granted by HBAC rule..." and sudo says
>>> simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.
>>>
>>> Btw. man sssd-sudo says:
>>> The following example shows how to configure SSSD to download
>>> sudo rules from an LDAP server.
>>>
>>>[sssd]
>>>config_file_version = 2
>>>services = nss, pam, sudo
>>>domains = EXAMPLE
>>>
>>>[domain/EXAMPLE]
>>>id_provider = ldap
>>>
>>> so I am not that sure what should be set on my version of sssd.
>>>
>>> Any idea?
>>>
>>> Thanks
>>>
>>> T.
>>>
>>> 2016-07-13 13:44 GMT+02:00 Lukas Slebodnik :
>>>
 On (13/07/16 13:36), Tomas Simecek wrote:
 >Lukas,
 >yes, I went through that guide and I configured sssd.conf as per the
 doc
 >(you can see it in the beginning of the thread).
 >
 >Actually the installation is:
 >[root@zp-cml-test sssd]# cat /etc/redhat-release
 >CentOS release 6.6 (Final)
 >
 >and versions are:
 >[root@zp-cml-test sssd]# rpm -qa |grep sssd
 >sssd-proxy-1.11.6-30.el6.x86_64
 >sssd-common-pac-1.11.6-30.el6.x86_64
 >sssd-ipa-1.11.6-30.el6.x86_64
 >sssd-1.11.6-30.el6.x86_64
 >sssd-common-1.11.6-30.el6.x86_64
 >sssd-ad-1.11.6-30.el6.x86_64
 >sssd-ldap-1.11.6-30.el6.x86_64
 >python-sssdconfig-1.11.6-30.el6.noarch
 >sssd-krb5-common-1.11.6-30.el6.x86_64
 >sssd-krb5-1.11.6-30.el6.x86_64
 >sssd-client-1.11.6-30.el6.x86_64
 >
 1.11 has sudo_provider=ipa

 @see instructions in man sssd-sudo how to configure it.
 It should avoid issues with two different providers (ipa and ldap)

 >
 >There are some reasons why not to upgrade to later versions, believe
 me, I
 >would do it if I could :-)
 >
 You can at least try to upgrade sssd from 6.8 if you do not want
 to upgrade whole OS.

 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
>>>
>>>
>>
>
-- 
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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Tomas Simecek

Thanks,
I will try. But I am afraid to update to more recent version then those in
official repos.

Thanks anyway.

T.

2016-07-13 15:39 GMT+02:00 :

> Update to at least 1.12 sssd and libsss_sudo. As I recall sudo ipa
> provider did not work under 1.11
>
> Sent from my iPhone
>
> On Jul 13, 2016, at 9:02 AM, Tomas Simecek 
> wrote:
>
> Hi,
> versions are:
> sssd-client-1.11.6-30.el6.x86_64
> sssd-ipa-1.11.6-30.el6.x86_64
> ipa-client-3.0.0-50.el6.centos.1.x86_64
> as part of:
> CentOS release 6.6 (Final)
>
> T.
>
> 2016-07-13 14:52 GMT+02:00 :
>
>> Again what is client version on 6.5?
>>
>>
>> Sent from my iPhone
>>
>> On Jul 13, 2016, at 8:25 AM, Tomas Simecek 
>> wrote:
>>
>> Thanks for your information Lukas,
>> I have changed sudo_provider to ipa, restarted sssd and no difference.
>> Logfile still says "Access granted by HBAC rule..." and sudo says
>> simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.
>>
>> Btw. man sssd-sudo says:
>> The following example shows how to configure SSSD to download
>> sudo rules from an LDAP server.
>>
>>[sssd]
>>config_file_version = 2
>>services = nss, pam, sudo
>>domains = EXAMPLE
>>
>>[domain/EXAMPLE]
>>id_provider = ldap
>>
>> so I am not that sure what should be set on my version of sssd.
>>
>> Any idea?
>>
>> Thanks
>>
>> T.
>>
>> 2016-07-13 13:44 GMT+02:00 Lukas Slebodnik :
>>
>>> On (13/07/16 13:36), Tomas Simecek wrote:
>>> >Lukas,
>>> >yes, I went through that guide and I configured sssd.conf as per the doc
>>> >(you can see it in the beginning of the thread).
>>> >
>>> >Actually the installation is:
>>> >[root@zp-cml-test sssd]# cat /etc/redhat-release
>>> >CentOS release 6.6 (Final)
>>> >
>>> >and versions are:
>>> >[root@zp-cml-test sssd]# rpm -qa |grep sssd
>>> >sssd-proxy-1.11.6-30.el6.x86_64
>>> >sssd-common-pac-1.11.6-30.el6.x86_64
>>> >sssd-ipa-1.11.6-30.el6.x86_64
>>> >sssd-1.11.6-30.el6.x86_64
>>> >sssd-common-1.11.6-30.el6.x86_64
>>> >sssd-ad-1.11.6-30.el6.x86_64
>>> >sssd-ldap-1.11.6-30.el6.x86_64
>>> >python-sssdconfig-1.11.6-30.el6.noarch
>>> >sssd-krb5-common-1.11.6-30.el6.x86_64
>>> >sssd-krb5-1.11.6-30.el6.x86_64
>>> >sssd-client-1.11.6-30.el6.x86_64
>>> >
>>> 1.11 has sudo_provider=ipa
>>>
>>> @see instructions in man sssd-sudo how to configure it.
>>> It should avoid issues with two different providers (ipa and ldap)
>>>
>>> >
>>> >There are some reasons why not to upgrade to later versions, believe
>>> me, I
>>> >would do it if I could :-)
>>> >
>>> You can at least try to upgrade sssd from 6.8 if you do not want
>>> to upgrade whole OS.
>>>
>>> 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
>>
>>
>
-- 
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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread ladner . danila

Update to at least 1.12 sssd and libsss_sudo. As I recall sudo ipa provider did 
not work under 1.11

Sent from my iPhone

> On Jul 13, 2016, at 9:02 AM, Tomas Simecek  wrote:
> 
> Hi,
> versions are:
> sssd-client-1.11.6-30.el6.x86_64
> sssd-ipa-1.11.6-30.el6.x86_64
> ipa-client-3.0.0-50.el6.centos.1.x86_64
> as part of:
> CentOS release 6.6 (Final)
> 
> T.
> 
> 2016-07-13 14:52 GMT+02:00 :
>> Again what is client version on 6.5?
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Jul 13, 2016, at 8:25 AM, Tomas Simecek  wrote:
>>> 
>>> Thanks for your information Lukas,
>>> I have changed sudo_provider to ipa, restarted sssd and no difference.
>>> Logfile still says "Access granted by HBAC rule..." and sudo says 
>>> simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.
>>> 
>>> Btw. man sssd-sudo says: 
>>> The following example shows how to configure SSSD to download
>>> sudo rules from an LDAP server.
>>> 
>>>[sssd]
>>>config_file_version = 2
>>>services = nss, pam, sudo
>>>domains = EXAMPLE
>>> 
>>>[domain/EXAMPLE]
>>>id_provider = ldap
>>> 
>>> so I am not that sure what should be set on my version of sssd.
>>> 
>>> Any idea?
>>> 
>>> Thanks
>>> 
>>> T.
>>> 
>>> 2016-07-13 13:44 GMT+02:00 Lukas Slebodnik :
 On (13/07/16 13:36), Tomas Simecek wrote:
 >Lukas,
 >yes, I went through that guide and I configured sssd.conf as per the doc
 >(you can see it in the beginning of the thread).
 >
 >Actually the installation is:
 >[root@zp-cml-test sssd]# cat /etc/redhat-release
 >CentOS release 6.6 (Final)
 >
 >and versions are:
 >[root@zp-cml-test sssd]# rpm -qa |grep sssd
 >sssd-proxy-1.11.6-30.el6.x86_64
 >sssd-common-pac-1.11.6-30.el6.x86_64
 >sssd-ipa-1.11.6-30.el6.x86_64
 >sssd-1.11.6-30.el6.x86_64
 >sssd-common-1.11.6-30.el6.x86_64
 >sssd-ad-1.11.6-30.el6.x86_64
 >sssd-ldap-1.11.6-30.el6.x86_64
 >python-sssdconfig-1.11.6-30.el6.noarch
 >sssd-krb5-common-1.11.6-30.el6.x86_64
 >sssd-krb5-1.11.6-30.el6.x86_64
 >sssd-client-1.11.6-30.el6.x86_64
 >
 1.11 has sudo_provider=ipa
 
 @see instructions in man sssd-sudo how to configure it.
 It should avoid issues with two different providers (ipa and ldap)
 
 >
 >There are some reasons why not to upgrade to later versions, believe me, I
 >would do it if I could :-)
 >
 You can at least try to upgrade sssd from 6.8 if you do not want
 to upgrade whole OS.
 
 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
> 
-- 
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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Tomas Simecek

Hi,
versions are:
sssd-client-1.11.6-30.el6.x86_64
sssd-ipa-1.11.6-30.el6.x86_64
ipa-client-3.0.0-50.el6.centos.1.x86_64
as part of:
CentOS release 6.6 (Final)

T.

2016-07-13 14:52 GMT+02:00 :

> Again what is client version on 6.5?
>
>
> Sent from my iPhone
>
> On Jul 13, 2016, at 8:25 AM, Tomas Simecek 
> wrote:
>
> Thanks for your information Lukas,
> I have changed sudo_provider to ipa, restarted sssd and no difference.
> Logfile still says "Access granted by HBAC rule..." and sudo says
> simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.
>
> Btw. man sssd-sudo says:
> The following example shows how to configure SSSD to download
> sudo rules from an LDAP server.
>
>[sssd]
>config_file_version = 2
>services = nss, pam, sudo
>domains = EXAMPLE
>
>[domain/EXAMPLE]
>id_provider = ldap
>
> so I am not that sure what should be set on my version of sssd.
>
> Any idea?
>
> Thanks
>
> T.
>
> 2016-07-13 13:44 GMT+02:00 Lukas Slebodnik :
>
>> On (13/07/16 13:36), Tomas Simecek wrote:
>> >Lukas,
>> >yes, I went through that guide and I configured sssd.conf as per the doc
>> >(you can see it in the beginning of the thread).
>> >
>> >Actually the installation is:
>> >[root@zp-cml-test sssd]# cat /etc/redhat-release
>> >CentOS release 6.6 (Final)
>> >
>> >and versions are:
>> >[root@zp-cml-test sssd]# rpm -qa |grep sssd
>> >sssd-proxy-1.11.6-30.el6.x86_64
>> >sssd-common-pac-1.11.6-30.el6.x86_64
>> >sssd-ipa-1.11.6-30.el6.x86_64
>> >sssd-1.11.6-30.el6.x86_64
>> >sssd-common-1.11.6-30.el6.x86_64
>> >sssd-ad-1.11.6-30.el6.x86_64
>> >sssd-ldap-1.11.6-30.el6.x86_64
>> >python-sssdconfig-1.11.6-30.el6.noarch
>> >sssd-krb5-common-1.11.6-30.el6.x86_64
>> >sssd-krb5-1.11.6-30.el6.x86_64
>> >sssd-client-1.11.6-30.el6.x86_64
>> >
>> 1.11 has sudo_provider=ipa
>>
>> @see instructions in man sssd-sudo how to configure it.
>> It should avoid issues with two different providers (ipa and ldap)
>>
>> >
>> >There are some reasons why not to upgrade to later versions, believe me,
>> I
>> >would do it if I could :-)
>> >
>> You can at least try to upgrade sssd from 6.8 if you do not want
>> to upgrade whole OS.
>>
>> 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
>
>
-- 
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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread ladner . danila

Again what is client version on 6.5?


Sent from my iPhone

> On Jul 13, 2016, at 8:25 AM, Tomas Simecek  wrote:
> 
> Thanks for your information Lukas,
> I have changed sudo_provider to ipa, restarted sssd and no difference.
> Logfile still says "Access granted by HBAC rule..." and sudo says 
> simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.
> 
> Btw. man sssd-sudo says: 
> The following example shows how to configure SSSD to download
> sudo rules from an LDAP server.
> 
>[sssd]
>config_file_version = 2
>services = nss, pam, sudo
>domains = EXAMPLE
> 
>[domain/EXAMPLE]
>id_provider = ldap
> 
> so I am not that sure what should be set on my version of sssd.
> 
> Any idea?
> 
> Thanks
> 
> T.
> 
> 2016-07-13 13:44 GMT+02:00 Lukas Slebodnik :
>> On (13/07/16 13:36), Tomas Simecek wrote:
>> >Lukas,
>> >yes, I went through that guide and I configured sssd.conf as per the doc
>> >(you can see it in the beginning of the thread).
>> >
>> >Actually the installation is:
>> >[root@zp-cml-test sssd]# cat /etc/redhat-release
>> >CentOS release 6.6 (Final)
>> >
>> >and versions are:
>> >[root@zp-cml-test sssd]# rpm -qa |grep sssd
>> >sssd-proxy-1.11.6-30.el6.x86_64
>> >sssd-common-pac-1.11.6-30.el6.x86_64
>> >sssd-ipa-1.11.6-30.el6.x86_64
>> >sssd-1.11.6-30.el6.x86_64
>> >sssd-common-1.11.6-30.el6.x86_64
>> >sssd-ad-1.11.6-30.el6.x86_64
>> >sssd-ldap-1.11.6-30.el6.x86_64
>> >python-sssdconfig-1.11.6-30.el6.noarch
>> >sssd-krb5-common-1.11.6-30.el6.x86_64
>> >sssd-krb5-1.11.6-30.el6.x86_64
>> >sssd-client-1.11.6-30.el6.x86_64
>> >
>> 1.11 has sudo_provider=ipa
>> 
>> @see instructions in man sssd-sudo how to configure it.
>> It should avoid issues with two different providers (ipa and ldap)
>> 
>> >
>> >There are some reasons why not to upgrade to later versions, believe me, I
>> >would do it if I could :-)
>> >
>> You can at least try to upgrade sssd from 6.8 if you do not want
>> to upgrade whole OS.
>> 
>> 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
-- 
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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Tomas Simecek

Thanks for your information Lukas,
I have changed sudo_provider to ipa, restarted sssd and no difference.
Logfile still says "Access granted by HBAC rule..." and sudo says
simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.

Btw. man sssd-sudo says:
The following example shows how to configure SSSD to download
sudo rules from an LDAP server.

   [sssd]
   config_file_version = 2
   services = nss, pam, sudo
   domains = EXAMPLE

   [domain/EXAMPLE]
   id_provider = ldap

so I am not that sure what should be set on my version of sssd.

Any idea?

Thanks

T.

2016-07-13 13:44 GMT+02:00 Lukas Slebodnik :

> On (13/07/16 13:36), Tomas Simecek wrote:
> >Lukas,
> >yes, I went through that guide and I configured sssd.conf as per the doc
> >(you can see it in the beginning of the thread).
> >
> >Actually the installation is:
> >[root@zp-cml-test sssd]# cat /etc/redhat-release
> >CentOS release 6.6 (Final)
> >
> >and versions are:
> >[root@zp-cml-test sssd]# rpm -qa |grep sssd
> >sssd-proxy-1.11.6-30.el6.x86_64
> >sssd-common-pac-1.11.6-30.el6.x86_64
> >sssd-ipa-1.11.6-30.el6.x86_64
> >sssd-1.11.6-30.el6.x86_64
> >sssd-common-1.11.6-30.el6.x86_64
> >sssd-ad-1.11.6-30.el6.x86_64
> >sssd-ldap-1.11.6-30.el6.x86_64
> >python-sssdconfig-1.11.6-30.el6.noarch
> >sssd-krb5-common-1.11.6-30.el6.x86_64
> >sssd-krb5-1.11.6-30.el6.x86_64
> >sssd-client-1.11.6-30.el6.x86_64
> >
> 1.11 has sudo_provider=ipa
>
> @see instructions in man sssd-sudo how to configure it.
> It should avoid issues with two different providers (ipa and ldap)
>
> >
> >There are some reasons why not to upgrade to later versions, believe me, I
> >would do it if I could :-)
> >
> You can at least try to upgrade sssd from 6.8 if you do not want
> to upgrade whole OS.
>
> 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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Lukas Slebodnik

On (13/07/16 13:36), Tomas Simecek wrote:
>Lukas,
>yes, I went through that guide and I configured sssd.conf as per the doc
>(you can see it in the beginning of the thread).
>
>Actually the installation is:
>[root@zp-cml-test sssd]# cat /etc/redhat-release
>CentOS release 6.6 (Final)
>
>and versions are:
>[root@zp-cml-test sssd]# rpm -qa |grep sssd
>sssd-proxy-1.11.6-30.el6.x86_64
>sssd-common-pac-1.11.6-30.el6.x86_64
>sssd-ipa-1.11.6-30.el6.x86_64
>sssd-1.11.6-30.el6.x86_64
>sssd-common-1.11.6-30.el6.x86_64
>sssd-ad-1.11.6-30.el6.x86_64
>sssd-ldap-1.11.6-30.el6.x86_64
>python-sssdconfig-1.11.6-30.el6.noarch
>sssd-krb5-common-1.11.6-30.el6.x86_64
>sssd-krb5-1.11.6-30.el6.x86_64
>sssd-client-1.11.6-30.el6.x86_64
>
1.11 has sudo_provider=ipa

@see instructions in man sssd-sudo how to configure it.
It should avoid issues with two different providers (ipa and ldap)

>
>There are some reasons why not to upgrade to later versions, believe me, I
>would do it if I could :-)
>
You can at least try to upgrade sssd from 6.8 if you do not want
to upgrade whole OS.

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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Tomas Simecek

Lukas,
yes, I went through that guide and I configured sssd.conf as per the doc
(you can see it in the beginning of the thread).

Actually the installation is:
[root@zp-cml-test sssd]# cat /etc/redhat-release
CentOS release 6.6 (Final)

and versions are:
[root@zp-cml-test sssd]# rpm -qa |grep sssd
sssd-proxy-1.11.6-30.el6.x86_64
sssd-common-pac-1.11.6-30.el6.x86_64
sssd-ipa-1.11.6-30.el6.x86_64
sssd-1.11.6-30.el6.x86_64
sssd-common-1.11.6-30.el6.x86_64
sssd-ad-1.11.6-30.el6.x86_64
sssd-ldap-1.11.6-30.el6.x86_64
python-sssdconfig-1.11.6-30.el6.noarch
sssd-krb5-common-1.11.6-30.el6.x86_64
sssd-krb5-1.11.6-30.el6.x86_64
sssd-client-1.11.6-30.el6.x86_64


There are some reasons why not to upgrade to later versions, believe me, I
would do it if I could :-)

T.


2016-07-13 13:27 GMT+02:00 Lukas Slebodnik :

> On (13/07/16 11:18), Tomas Simecek wrote:
> >Dear freeIPA gurus,
> >in previous thread (
> >https://www.redhat.com/archives/freeipa-users/2016-July/msg00046.html)
> you
> >helped me make sudo working for AD users on Centos 7.0 (
> >spcss-2t-www.linuxdomain.cz).
> >It was caused by not knowing sudo needs to be enabled in HBAC rules.
> >Now it works properly on Centos 7.0 client.
> >But it does not work on Centos 6.5 (zp-cml-test.linuxdomain.cz) with the
> >same sssd.conf setup.
> >Error message is always:
> >
> A) I would not recommend to use such obsolete distribution as CentOS 6.5
>There is quite old version of sssd (1.9.x) which has some bugs which
>are solved in later versions. Better would be use the latest CentOS 6.8
>or at least CentOS 6.7
>
> B) Have you tried to follow instructions
>https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO
>
> Please provide any comments how we can improve troubleshooting wiki.
>
> 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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Lukas Slebodnik

On (13/07/16 11:18), Tomas Simecek wrote:
>Dear freeIPA gurus,
>in previous thread (
>https://www.redhat.com/archives/freeipa-users/2016-July/msg00046.html) you
>helped me make sudo working for AD users on Centos 7.0 (
>spcss-2t-www.linuxdomain.cz).
>It was caused by not knowing sudo needs to be enabled in HBAC rules.
>Now it works properly on Centos 7.0 client.
>But it does not work on Centos 6.5 (zp-cml-test.linuxdomain.cz) with the
>same sssd.conf setup.
>Error message is always:
>
A) I would not recommend to use such obsolete distribution as CentOS 6.5
   There is quite old version of sssd (1.9.x) which has some bugs which
   are solved in later versions. Better would be use the latest CentOS 6.8
   or at least CentOS 6.7

B) Have you tried to follow instructions
   https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

Please provide any comments how we can improve troubleshooting wiki.

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] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Tomas Simecek

Diky Jakube,
in domain log below I can see that rules were found properly:
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x1000): Processing PAM services for rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x2000): Added service [login] to rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x2000): Added service [sshd] to rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x2000): Added service [sudo] to rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x2000): Added service [sudo-i] to rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x2000): Added service [su] to rule [Unixari
na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_service_attrs_to_rule] (0x2000): Added service [su-l] to rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule
[Unixari na test servery]

It also matches the rule and says "Access granted":
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_host_attrs_to_rule] (0x1000):
[fqdn=spcss-2t-www.linuxdomain.cz,cn=computers,cn=accounts,dc=linuxdomain,dc=cz]
does not map to either a host or hostgroup. Skipping
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_host_attrs_to_rule] (0x2000): Added host [zp-cml-test.linuxdomain.cz]
to rule [Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule
[Unixari na test servery]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_shost_attrs_to_rule] (0x2000): Source hosts disabled, setting ALL
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_eval_user_element] (0x1000): [1] groups for [simecek.to...@sd-stc.cz]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[hbac_eval_user_element] (0x1000): Added group [grpunixadmins] for user [
simecek.to...@sd-stc.cz]
(Wed Jul 13 12:05:21 2016) [sssd[be[linuxdomain.cz]]]
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [Unixari na
test servery]

It also mentiones SELinux, but I know it is disabled.

Any idea what to check next please?
Full part of the log follows:

(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [be_get_account_info]
(0x0100): Got request for [3][1][name=simecek.tomas]
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [be_req_set_domain]
(0x0400): Changing request domain from [linuxdomain.cz] to [sd-stc.cz]
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]]
[ipa_get_subdom_acct_send] (0x0400): Initgroups requests are not handled by
the IPA provider but are resolved by the responder directly from the cache.
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [acctinfo_callback]
(0x0100): Request processed. Returned 3,95,Account info lookup failed
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [be_req_set_domain]
(0x0400): Changing request domain from [linuxdomain.cz] to [sd-stc.cz]
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [be_pam_handler]
(0x0100): Got request with the following data
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): command: PAM_AUTHENTICATE
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): domain: sd-stc.cz
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): user: simecek.to...@sd-stc.cz
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): service: sudo
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): tty: /dev/pts/0
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): ruser: simecek.to...@sd-stc.cz
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): rhost:
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): authtok type: 1
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): newauthtok type: 0
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): priv: 0
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [pam_print_data]
(0x0100): cli_pid: 27305
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [switch_creds]
(0x0200): Switch user to [988604700][988604700].
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]]
[sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired.
(Wed Jul 13 12:05:20 2016) [sssd[be[linuxdomain.cz]]] [switch_creds]
(0x0200): Switch user to [0][0].
(Wed Jul 13 12:05:20 2016)

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Jakub Hrozek

On Wed, Jul 13, 2016 at 11:18:21AM +0200, Tomas Simecek wrote:
> Dear freeIPA gurus,
> in previous thread (
> https://www.redhat.com/archives/freeipa-users/2016-July/msg00046.html) you
> helped me make sudo working for AD users on Centos 7.0 (
> spcss-2t-www.linuxdomain.cz).
> It was caused by not knowing sudo needs to be enabled in HBAC rules.
> Now it works properly on Centos 7.0 client.
> But it does not work on Centos 6.5 (zp-cml-test.linuxdomain.cz) with the
> same sssd.conf setup.
> Error message is always:
> 
> [simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
> [sudo] password for simecek.to...@sd-stc.cz:
> simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.  This
> incident will be reported.
> 
> Here are my HBAC rules, the second one should apply. It definitely applies
> for Centos 7.0 server:
> [root@svlxxipap ~]# ipa hbacrule-find
> 
> 2 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: Unixari na test servery
>   Enabled: TRUE
>   User Groups: grpunixadmins
>   Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
>   Services: login, sshd, sudo, sudo-i, su, su-l
> 
> Number of entries returned 2
> 
> 
> This is my /etc/sssd/sssd.conf. It the same like on Centos 7.0 server, just
> with proper server name of course:
> 
> [root@zp-cml-test sssd]# cat /etc/sssd/sssd.conf
> [domain/linuxdomain.cz]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = linuxdomain.cz
> id_provider = ipa
> krb5_realm = LINUXDOMAIN.CZ
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = zp-cml-test.linuxdomain.cz
> chpass_provider = ipa
> ipa_server = svlxxipap.linuxdomain.cz
> ldap_tls_cacert = /etc/ipa/ca.crt
> override_shell = /bin/bash
> sudo_provider = ldap
> ldap_uri = ldap://svlxxipap.linuxdomain.cz
> ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
> ldap_sasl_mech = GSSAPI
> #ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
> ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
> ldap_sasl_realm = LINUXDOMAIN.CZ
> krb5_server = svlxxipap.linuxdomain.cz
> 
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> debug_level = 0x3ff0
> domains = linuxdomain.cz
> [nss]
> homedir_substring = /home
> 
> [pam]
> [sudo]
> debug_level = 0x3ff0
> [autofs]
> [ssh]
> [pac]
> [ifp]
> 
> This is output from sssd_sudo.log:
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [accept_fd_handler] (0x0400):
> Client connected!
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
> Received client version [1].
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
> Offered version [1].
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using
> protocol version [1]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_parse_name_for_domains]
> (0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
> sd-stc.cz', user is simecek.tomas
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_parse_name_for_domains]
> (0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
> sd-stc.cz', user is simecek.tomas
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
> (0x0200): Requesting default options for [simecek.tomas] from [sd-stc.cz]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_user] (0x0200):
> Requesting info about [simecek.to...@sd-stc.cz]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_user] (0x0400):
> Returning info for user [simecek.to...@sd-stc.cz]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
> Retrieving default options for [simecek.to...@sd-stc.cz] from [sd-stc.cz]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
> (0x0400): No such entry
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
> (0x0200): Searching sysdb with
> [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
> simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain
> us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz)(sudoUser=%
> mfcr_...@sd-stc.cz)(sudoUser=%acco...@sd-stc.cz)(sudoUser=%w...@sd-stc.cz
> )(sudoUser=%grpunixadmins)(sudoUser=+*))(&(dataExpireTimestamp<=1468393118)))]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
> to get sudo rules from cache
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
> (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
> (0x0400): Returning 0 rules for [@sd-stc.cz]
> (Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using
> protocol version [1]
> (Wed Jul 13 08:58:38 2016)

Re: [Freeipa-users] Unable to ssh after establishing trust

2016-07-13 Thread Sumit Bose

On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> +freeipa-users list
> 
>   From: pgb205 
>  To: Sumit Bose  
>  Sent: Tuesday, July 12, 2016 2:12 PM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>
> Sumit, thanks for replying
> So the first issue is my fault, probably from when I was sanitizing logs. 
> our active directory domain is ad_domain.local, but users would expect to 
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is 
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> ewr-fipa_server used to be old trial server so I am not sure why it's still 
> in the dns lookup results. I'll check this part further.
> Lastly. only the connection to one of the domain controllers on AD side is 
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf, a connection to this single, accessible domain controller. 
> Are there any other files where I would needto lock down the connections 
> between ipa->ad so that all traffic goes to specific active directory domain 
> controller?
> thanks again for replying so quickly.

Currently it is not possible to specify individual AD DC SSSD on the IPA
server should talk to. We have ticket
https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
later versions of SSSD. 

Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
get a list of AD DC, then picks one to get the next nearest site for the
IPA domain and finally tries to lookup a DC from the matching site (if
any).

According to your logs SSSD was able to find 18 DCs with the SRV lookup.
A call like

dig SRV _ldap._tcp.ad_domain.local

on the IPA server should return the same list of 18 DCs.

As a work-around, or better a hack, you might want to try to set the IP
address of all the 18 DC returned to the IP address of the only
accessible DC in /etc/hosts. This way SSSD should have no chance to
connect to a different DC.

bye,
Sumit

> 
>   From: Sumit Bose 
>  To: pgb205  
> Cc: Sumit Bose 
>  Sent: Tuesday, July 12, 2016 5:37 AM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>   
> On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > Sumit, 
> > sssd log files attached with debug=10 in all sections.I have attempted 
> > several logins for comparison as well as kinit commands
> 
> I came across two issues in the logs.
> 
> First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
> AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
> FreeIPA cannot resolve those principals correctly. It was planned for
> IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
> be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
> please try to work-around suggested at the end of
> http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
> authenticate with user@AD_DOMAIN.COM SSSD looks for a server called
> ewr-fipa_server.ad_domain.com but cannot find it an return the error code
> for "Cannot contact any KDC for requested realm".
> 
> Second there are some issues access AD DCs via LDAP. SSSD tries to
> connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but
> both fails. It is not clear from the logs if already the DNS lookup for
> those fails or if the connection itself runs into a timeout. In the
> former case you should make sure that the names can be resolved in the
> IPA server in the latter you can try to increase ldap_network_timeout
> (see man sssd-ldap for details). Since SSSD cannot connect to the DCs it
> switches the AD domains to offline. The authentication request is
> handled offline as well but since there are no cached credentials you
> get the permission denied error.
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> >      From: Sumit Bose 
> >  To: pgb205  
> > Cc: "Freeipa-users@redhat.com" 
> >  Sent: Monday, July 11, 2016 3:06 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >    
> > On Mon, Jul 11, 2016 at 03:46:57AM +, pgb205 wrote:
> > > I have successfully established trust and am able to obtain ticket 
> > > granting ticketkinit user@AD_DOMAIN.COMI can also do kinit 
> > > admin@IPA_DOMAIN.COMssh admin@IPA_DOMAIN.COM also works
> > > however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails
> > > I have checked that there are no hbac rules other then the default 
> > > allow_all rule
> > > in sssd_ssh.log see
> > > permission denied (6) error in sssd_ipa.domain.log file I see
> > > pam_handler_callback 6 permission_denied
> > > in sssd_nss.log Unable to get information from Data ProviderError: 3 
> > > Account info lookup failedWill try to return what we have in cache
> > > in

[Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

2016-07-13 Thread Tomas Simecek

Dear freeIPA gurus,
in previous thread (
https://www.redhat.com/archives/freeipa-users/2016-July/msg00046.html) you
helped me make sudo working for AD users on Centos 7.0 (
spcss-2t-www.linuxdomain.cz).
It was caused by not knowing sudo needs to be enabled in HBAC rules.
Now it works properly on Centos 7.0 client.
But it does not work on Centos 6.5 (zp-cml-test.linuxdomain.cz) with the
same sssd.conf setup.
Error message is always:

[simecek.to...@sd-stc.cz@zp-cml-test ~]$ sudo cat /etc/nsswitch.conf
[sudo] password for simecek.to...@sd-stc.cz:
simecek.to...@sd-stc.cz is not allowed to run sudo on zp-cml-test.  This
incident will be reported.

Here are my HBAC rules, the second one should apply. It definitely applies
for Centos 7.0 server:
[root@svlxxipap ~]# ipa hbacrule-find

2 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: Unixari na test servery
  Enabled: TRUE
  User Groups: grpunixadmins
  Hosts: spcss-2t-www.linuxdomain.cz, zp-cml-test.linuxdomain.cz
  Services: login, sshd, sudo, sudo-i, su, su-l

Number of entries returned 2


This is my /etc/sssd/sssd.conf. It the same like on Centos 7.0 server, just
with proper server name of course:

[root@zp-cml-test sssd]# cat /etc/sssd/sssd.conf
[domain/linuxdomain.cz]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = linuxdomain.cz
id_provider = ipa
krb5_realm = LINUXDOMAIN.CZ
auth_provider = ipa
access_provider = ipa
ipa_hostname = zp-cml-test.linuxdomain.cz
chpass_provider = ipa
ipa_server = svlxxipap.linuxdomain.cz
ldap_tls_cacert = /etc/ipa/ca.crt
override_shell = /bin/bash
sudo_provider = ldap
ldap_uri = ldap://svlxxipap.linuxdomain.cz
ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
ldap_sasl_mech = GSSAPI
#ldap_sasl_authid = host/zp-cml-test.linuxdomain...@linuxdomain.cz
ldap_sasl_authid = host/zp-cml-test.linuxdomain.cz
ldap_sasl_realm = LINUXDOMAIN.CZ
krb5_server = svlxxipap.linuxdomain.cz

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
debug_level = 0x3ff0
domains = linuxdomain.cz
[nss]
homedir_substring = /home

[pam]
[sudo]
debug_level = 0x3ff0
[autofs]
[ssh]
[pac]
[ifp]

This is output from sssd_sudo.log:
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [accept_fd_handler] (0x0400):
Client connected!
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using
protocol version [1]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
sd-stc.cz', user is simecek.tomas
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
sd-stc.cz', user is simecek.tomas
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_cmd_parse_query_done]
(0x0200): Requesting default options for [simecek.tomas] from [sd-stc.cz]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_user] (0x0200):
Requesting info about [simecek.to...@sd-stc.cz]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_user] (0x0400):
Returning info for user [simecek.to...@sd-stc.cz]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400):
Retrieving default options for [simecek.to...@sd-stc.cz] from [sd-stc.cz]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sysdb_search_group_by_gid]
(0x0400): No such entry
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=
simecek.to...@sd-stc.cz)(sudoUser=#988604700)(sudoUser=%domain
us...@sd-stc.cz)(sudoUser=%unixadm...@sd-stc.cz)(sudoUser=%
mfcr_...@sd-stc.cz)(sudoUser=%acco...@sd-stc.cz)(sudoUser=%w...@sd-stc.cz
)(sudoUser=%grpunixadmins)(sudoUser=+*))(&(dataExpireTimestamp<=1468393118)))]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About
to get sudo rules from cache
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache]
(0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache]
(0x0400): Returning 0 rules for [@sd-stc.cz]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sudosrv_cmd] (0x2000): Using
protocol version [1]
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
sd-stc.cz', user is simecek.tomas
(Wed Jul 13 08:58:38 2016) [sssd[sudo]] [sss_parse_name_for_domains]
(0x0200): name 'simecek.to...@sd-stc.cz' matched expression for domain '
sd-stc.cz',

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-13 Thread Sumit Bose

On Wed, Jul 13, 2016 at 08:37:44AM +0200, Jakub Hrozek wrote:
> On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
> > On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] wrote:
> > > Justin,
> > > 
> > > I really appreciate you taking the time to respond to me.  This problem
> > > is driving me crazy and I will certainly take any help I can get. My
> > > suspicion is that the external user group in the policy below was
> > > causing the log entry you specified, removing it from the policy does
> > > not remediate the problem, even after flushing the client cache.
> > > 
> > > The way I have this setup is as follows:
> > > 
> > > 1) I created a POSIX group in IPA named
> > > 'cri-cri_server_administrators_ipa' and allowed IPA to assign the GID.
> > > 2) I created an external group in IPA named
> > > 'cri-cri_server_administrators_external’ and added the AD group in the
> > > trusted domain as an external member to this group
> > > (cri-cri_server_administrat...@bsdad.uchicago.edu).
> > > 3) I added the group cri-cri_server_administrators_external' as a
> > > member of 'cri-cri_server_administrators_ipa’
> > > 
> > > The HBAC rule is configured as (removing the external group does not
> > > seem to make a difference).
> > > 
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > > 'cri-cri_server_administrators_allow_all'
> > >  Rule name: cri-cri_server_administrators_allow_all
> > >  Host category: all
> > >  Service category: all
> > >  Description: Allow anyone in 
> > > cri-cri_server_administrat...@bsdad.uchicago.edu
> > >  to login to any machine
> > >  Enabled: TRUE
> > >  User Groups: cri-cri_server_administrators_external, 
> > > cri-cri_server_administrators_ipa
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]#
> > > 
> > > For example, the problem still persists when the policy is configured in 
> > > this manner:
> > > 
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > > 'cri-cri_server_administrators_allow_all'
> > >  Rule name: cri-cri_server_administrators_allow_all
> > >  Host category: all
> > >  Service category: all
> > >  Description: Allow anyone in 
> > > cri-cri_server_administrat...@bsdad.uchicago.edu to login to any machine
> > >  Enabled: TRUE
> > >  User Groups: cri-cri_server_administrators_ipa
> > > 
> > > And my login validates against the host in question as follows:
> > > 
> > > As I said I have this working consistently (i.e. can flush the cash) on
> > > another host with the same exact version of IPA and SSSD.  Here is a
> > > validation of hbactest (works with either of the two policy
> > > configurations above).
> > I think you problems are related to this snippet of your domain log
> > where SSSD on IPA client was unable to add membership of your user to
> > any of these groups:
> > 

...

> > 
> > as result, the user is viewed by SSSD on this IPA client as not
> > belonging to the cri-cri_server_administrat...@bsdad.uchicago.edu group
> > and thus, HBAC rule validation on this client fails.
> 
> First, we have some debug messages in this part of sssd that can really
> use some improvement. That is, some debug messages are expected to
> report failures and we recover from them later.
> 
> But in general Alexander is right. Does 'id
> a.cri.dsulli...@bsdad.uchicago.edu' report the user as a member of the
> group that should be allowing access?
> 
> If not, I would suggest to run:
> 1) sss_cache -E on both server and client (don't remove the cache,
> please)
> 2) truncate the logs on server and client
> 3) run id a.cri.dsulli...@bsdad.uchicago.edu on the client
> then send us the logs from that single id run..

If some of the IPA group memberships are missing you might hit
https://bugzilla.redhat.com/show_bug.cgi?id=1304333 which is not fixed
in the IPA version you use (ipa-4.2.0-15.el7_2.6.1).

Mabye upgrading the server helps?

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] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

2016-07-13 Thread Jakub Hrozek

On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
> On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] wrote:
> > Justin,
> > 
> > I really appreciate you taking the time to respond to me.  This problem
> > is driving me crazy and I will certainly take any help I can get. My
> > suspicion is that the external user group in the policy below was
> > causing the log entry you specified, removing it from the policy does
> > not remediate the problem, even after flushing the client cache.
> > 
> > The way I have this setup is as follows:
> > 
> > 1) I created a POSIX group in IPA named
> > 'cri-cri_server_administrators_ipa' and allowed IPA to assign the GID.
> > 2) I created an external group in IPA named
> > 'cri-cri_server_administrators_external’ and added the AD group in the
> > trusted domain as an external member to this group
> > (cri-cri_server_administrat...@bsdad.uchicago.edu).
> > 3) I added the group cri-cri_server_administrators_external' as a
> > member of 'cri-cri_server_administrators_ipa’
> > 
> > The HBAC rule is configured as (removing the external group does not
> > seem to make a difference).
> > 
> > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > 'cri-cri_server_administrators_allow_all'
> >  Rule name: cri-cri_server_administrators_allow_all
> >  Host category: all
> >  Service category: all
> >  Description: Allow anyone in 
> > cri-cri_server_administrat...@bsdad.uchicago.edu
> >  to login to any machine
> >  Enabled: TRUE
> >  User Groups: cri-cri_server_administrators_external, 
> > cri-cri_server_administrators_ipa
> > [root@cri-ksysipadcp2 a.cri.dsullivan]#
> > 
> > For example, the problem still persists when the policy is configured in 
> > this manner:
> > 
> > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > 'cri-cri_server_administrators_allow_all'
> >  Rule name: cri-cri_server_administrators_allow_all
> >  Host category: all
> >  Service category: all
> >  Description: Allow anyone in 
> > cri-cri_server_administrat...@bsdad.uchicago.edu to login to any machine
> >  Enabled: TRUE
> >  User Groups: cri-cri_server_administrators_ipa
> > 
> > And my login validates against the host in question as follows:
> > 
> > As I said I have this working consistently (i.e. can flush the cash) on
> > another host with the same exact version of IPA and SSSD.  Here is a
> > validation of hbactest (works with either of the two policy
> > configurations above).
> I think you problems are related to this snippet of your domain log
> where SSSD on IPA client was unable to add membership of your user to
> any of these groups:
> 
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [get_groups_dns] (0x0400): Root domain uses fully-qualified names,
> objects might not be correctly added to groups with short names.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [get_groups_dns] (0x0400): Root domain uses fully-qualified names,
> objects might not be correctly added to groups with short names.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [ipa_s2n_save_objects] (0x2000): Updating memberships for
> a.cri.dsulli...@bsdad.uchicago.edu
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_update_members_ex] (0x0020): Could not add member
> [a.cri.dsulli...@bsdad.uchicago.edu] to group
> [name=cri-aaa_sms_administrat...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
> Skipping.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_update_members_ex] (0x0020): Could not add member
> [a.cri.dsulli...@bsdad.uchicago.edu] to group
> [name=cri-aaa_cvs_reposit...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
> Skipping.
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> object](32)[ldb_wait: No such object (32)]
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_mod_group_member] (0x0400): Error: 2 (No such file or directory)
> (Tue Jul 12 13:29:58 2016) [sssd[be[ipa.cri.uchicago.edu]]]
> [sysdb_update_members_ex] (0x0020): Could not add member
> [a.cri.dsulli...@bsdad.uchicago.edu] to group
> [name=cri-active_us...@bsdad.uchicago.edu,cn=groups,cn=bsdad.uchicago.edu,cn=sysdb].
> Skipping.
> (Tue Jul 12

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

Re: [Freeipa-users] FreeIPA (Add Replica fails on GSSAPI)

Re: [Freeipa-users] Deny bind for external LDAP if password is expired

Re: [Freeipa-users] HBAC and AD users

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

[Freeipa-users] named-pkcs11 fails to start on new replica

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

Re: [Freeipa-users] Web UI access from outside the home network via port forwarding

Re: [Freeipa-users] (DRAFT) HA mail services with FreeIPA, postfix, dovecot, amavisd-new, clamd and PLAIN/GSSAPI SSO

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] Unable to ssh after establishing trust

[Freeipa-users] sudo - differences between Centos 6.5 and Centos 7.0?

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

27 matches

Site Navigation

Mail list logo

Footer information