Re: [Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4

2016-02-19 Thread Lukas Slebodnik 
On (19/02/16 16:04), Jakub Hrozek wrote:
>On Fri, Feb 19, 2016 at 03:27:50PM +0100, Harald Dunkel wrote:
>> Hi Lukas,
>> 
>> I found an ubuntu manpage saying sss_ssh_knownhostsproxy is
>> an experimental feature. 
>> Would you suggest to drop it
>> in ipa-client-install?
>
>It's not experimental (at least upstream) for several years.. What sssd
>version is that?
>
@see subject :-)

>> 
>> IMHO this is a pretty annoying bug. I rely upon a port
>> redirection for ssh on IPv4. For IPv6 there is no
>> redirection, but the port is blocked in the packet filter.
>
>Would it help to set lookup_family_order to ipv4_only here so that ipv6
>is not even tried (or the other way around, depending on which AF you
>want to try..)
>
I briefly look at the source code and it does not seems to read sssd.conf.

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] Wildcards in sudo external hostnames

2016-02-19 Thread Jakub Hrozek 
On Fri, Feb 19, 2016 at 09:10:19PM +0530, Prashant Bapat wrote:
> Not using SSSD because Amazon Linux does not support samba libraries
> required to compile it.

Time to file a request against Amazon I guess :-)

-- 
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] Wildcards in sudo external hostnames

2016-02-19 Thread Prashant Bapat 
Not using SSSD because Amazon Linux does not support samba libraries
required to compile it.

On 19 February 2016 at 14:28, Jakub Hrozek  wrote:

> On Fri, Feb 19, 2016 at 11:27:16AM +0530, Prashant Bapat wrote:
> > Hi,
> >
> > I'm using FreeIPA 4.1.4 with nss-pam-ldapd and the compat schema.
>
> Why not sssd?
>
> >
> > I'm thinking of moving sudo rules to IPA and with *ou=sudoers* and
> > sudo-ldap this works.
> >
> > In our setup we have lot of rules with wildcard matching for sudo
> > hostnames. For ex webserver*, dbserver* etc.
> >
> > In the IPA UI, when I try to add the hostname with wildcard (*) char I
> get
> > an error from UI. * is not allowed char.
> >
> > Looks like the UI is trying to validate the hostname using
> > validate_dns_label in ipa/util.py and obviously * is not one of the
> allowed
> > chars.
> >
> > Taking a look at the documentation of sudo, wildcards are pretty widely
> > used. More info here
> > https://www.sudo.ws/man/1.8.15/sudoers.man.html#x57696c646361726473
> >
> > Other than editing the LDAP schema outside of IPA (this will work) what
> are
> > the other options to solve this ?
>
> I guess hostgroups/netgroups are even better (more explicit) than
> wildcards.
>
> --
> 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] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4

2016-02-19 Thread Jakub Hrozek 
On Fri, Feb 19, 2016 at 03:27:50PM +0100, Harald Dunkel wrote:
> Hi Lukas,
> 
> I found an ubuntu manpage saying sss_ssh_knownhostsproxy is
> an experimental feature. 
> Would you suggest to drop it
> in ipa-client-install?

It's not experimental (at least upstream) for several years.. What sssd
version is that?

> 
> IMHO this is a pretty annoying bug. I rely upon a port
> redirection for ssh on IPv4. For IPv6 there is no
> redirection, but the port is blocked in the packet filter.

Would it help to set lookup_family_order to ipv4_only here so that ipv6
is not even tried (or the other way around, depending on which AF you
want to try..)

-- 
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] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4

2016-02-19 Thread Harald Dunkel 
Hi Lukas,

I found an ubuntu manpage saying sss_ssh_knownhostsproxy is
an experimental feature. Would you suggest to drop it
in ipa-client-install?

IMHO this is a pretty annoying bug. I rely upon a port
redirection for ssh on IPv4. For IPv6 there is no
redirection, but the port is blocked in the packet filter.


Regards
Harri

-- 
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] IPA 4.2.0 httpd errors

2016-02-19 Thread Daryl Fonseca-Holt 

Hello,

Doing a bulk load of 150,000+ users to an IPA 4.2.0 server running 
RedHat Enterprise Linux 7.


Running 25 parallel ipa user-add at once, waiting for completion, then 
starting another 25, and so on.


The httpd error_log is filling with many of these messages (457,189 in 
four days):


[Fri Feb 19 07:41:08.100903 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] mod_wsgi (pid=76505): Exception occurred processing WSGI 
script '/usr/share/ipa/wsgi.py'.
[Fri Feb 19 07:41:08.100989 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] Traceback (most recent call last):
[Fri Feb 19 07:41:08.101018 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File "/usr/share/ipa/wsgi.py", line 49, in application
[Fri Feb 19 07:41:08.101073 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] return api.Backend.wsgi_dispatch(environ, start_response)
[Fri Feb 19 07:41:08.101087 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 258, in 
__call__
[Fri Feb 19 07:41:08.101109 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] return self.route(environ, start_response)
[Fri Feb 19 07:41:08.101120 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 270, in 
route
[Fri Feb 19 07:41:08.101140 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] return app(environ, start_response)
[Fri Feb 19 07:41:08.101152 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 447, in 
__call__
[Fri Feb 19 07:41:08.101169 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] response = super(jsonserver, self).__call__(environ, 
start_response)
[Fri Feb 19 07:41:08.101180 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 647, in 
__call__
[Fri Feb 19 07:41:08.101198 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] 'xmlserver', user_ccache, environ, start_response, 
headers)
[Fri Feb 19 07:41:08.101210 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 593, in 
finalize_kerberos_acquisition
[Fri Feb 19 07:41:08.101229 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] session_data['ccache_data'] = 
load_ccache_data(ccache_name)
[Fri Feb 19 07:41:08.101240 2016] [:error] [pid 76505] [remote 
10.0.1.177:40]   File 
"/usr/lib/python2.7/site-packages/ipalib/session.py", line 1231, in 
load_ccache_data
[Fri Feb 19 07:41:08.101259 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] src = open(name)
[Fri Feb 19 07:41:08.101294 2016] [:error] [pid 76505] [remote 
10.0.1.177:40] IOError: [Errno 2] No such file or directory: 
'/var/run/httpd/ipa/clientcaches/admin@UOFMT1'
[Fri Feb 19 07:41:09.788839 2016] [auth_gssapi:error] [pid 75336] 
[client 10.0.1.177:42610] failed to store delegated creds: [Unspecified 
GSS failure.  Minor code may provide more information (Internal 
credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml
[Fri Feb 19 07:41:09.788844 2016] [auth_gssapi:error] [pid 78642] 
[client 10.0.1.177:42621] failed to store delegated creds: [Unspecified 
GSS failure.  Minor code may provide more information (Internal 
credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml
[Fri Feb 19 07:41:09.788961 2016] [auth_gssapi:error] [pid 78643] 
[client 10.0.1.177:42613] failed to store delegated creds: [Unspecified 
GSS failure.  Minor code may provide more information (Internal 
credentials cache error)], referer: https://mork.cc.umanitoba.ca/ipa/xml
[Fri Feb 19 07:41:09.789154 2016] [auth_gssapi:error] [pid 77367] 
[client 10.0.1.177:42615] KRB5CCNAME file 
(/var/run/httpd/ipa/clientcaches/admin@UOFMT1) lookup failed!, referer: 
https://mork.cc.umanitoba.ca/ipa/xml



When the batches are first started there are no errors.
Started batch script at 11:34:54. First error at 12:17:31 after 48 
batches of 25 users.


The 25 users are each added concurrently by separate processes using ipa 
user-add  ...
When the script gets the authentication error it simply retries the 
user-add so the user are added anyway.


I think there was a similiar incident, Subject: Client-Install failures 
in January 2016 but the thread seemed to fade away without an answer AFAICT.


Thanks, Daryl

--
 --
 Daryl Fonseca-Holt
 IST/CNS/Unix Server Team
 University of Manitoba
 204.480.1079

--
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] DNS operation timed out when installing IPA with forwarders

2016-02-19 Thread Martin Basti 



On 19.02.2016 14:57, Geselle Stijn wrote:

That seems to fail:

[root@ipa ~]# dig @192.168.1.1 . SOA

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> @192.168.1.1 . SOA ; (1 server 
found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44900 ;; flags: qr rd ra; 
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;.  IN  SOA

;; Query time: 11153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Feb 19 14:42:51 CET 2016
;; MSG SIZE  rcvd: 28


But if I add a new record (e.g. CNAME) to DNS in Windows Server and try to ping 
to that CNAME, I get resolved correctly.

-Stijn

Hello,

global forwarders, specified by --forwarder option during installation 
or added via ipa dnsconfig-mod, must be able to resolve root zone (your 
forwarder/server 192.168.1.1 is not able to return result for root zone).


You probably need to specify forwardzone, for the particular windows 
domain you use, instead of specify it as global forwarder.


ipa dnsforwardzone-add  --forwarder 192.168.1.1

Martin


-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek
Sent: Friday 19 February 2016 13:59
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] DNS operation timed out when installing IPA with 
forwarders

On 19.2.2016 13:50, Geselle Stijn wrote:

Hello fellow FreeIPA users,

I'm trying to setup FreeIPA in a lab environment (VirtualBox):


-  ad.example.com (Windows Server 2008 R2) - 192.168.1.1

-  ipa.example.com (CentOS 7.2) - 192.168.1.2
Both machines can ping each other, DNS resolving works:

[root@ipa ~] nslookup ad
Server: 192.168.1.1
Address: 192.168.1.1#53

Name: ad.example.com
Address: 192.168.1.1


I executed:

yum install -y "*ipa-server*" bind bind-dyndb-ldap ipa-server-install
--domain=example.com --realm=EXAMPLE.COM --setup-dns
--forwarder=192.168.1.1

But the installation wizard fails at:

Checking DNS forwarders, please wait ...
ipa: ERROR   DNS server 192.168.1.1: query '. SOA': The DNS 
operation timed out after 10.00124242 seconds
ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 
192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 
seconds


Is there some way I can better troubleshoot this? Can I increase the DNS 
timeout (maybe it's simply slow via VirtualBox).

Please try command
$ dig @192.168.1.1 . SOA
and paste the output here.

Also, please run the installer again with option --debug.

I will have a look.

Thank you.

--
Petr^2 Spacek

--
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] DNS operation timed out when installing IPA with forwarders

2016-02-19 Thread Geselle Stijn 
That seems to fail:

[root@ipa ~]# dig @192.168.1.1 . SOA

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.2 <<>> @192.168.1.1 . SOA ; (1 server 
found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44900 ;; flags: qr rd ra; 
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;.  IN  SOA

;; Query time: 11153 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Feb 19 14:42:51 CET 2016
;; MSG SIZE  rcvd: 28


But if I add a new record (e.g. CNAME) to DNS in Windows Server and try to ping 
to that CNAME, I get resolved correctly.

-Stijn

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Petr Spacek
Sent: Friday 19 February 2016 13:59
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] DNS operation timed out when installing IPA with 
forwarders

On 19.2.2016 13:50, Geselle Stijn wrote:
> Hello fellow FreeIPA users,
> 
> I'm trying to setup FreeIPA in a lab environment (VirtualBox):
> 
> 
> -  ad.example.com (Windows Server 2008 R2) - 192.168.1.1
> 
> -  ipa.example.com (CentOS 7.2) - 192.168.1.2
> Both machines can ping each other, DNS resolving works:
> 
> [root@ipa ~] nslookup ad
> Server: 192.168.1.1
> Address: 192.168.1.1#53
> 
> Name: ad.example.com
> Address: 192.168.1.1
> 
> 
> I executed:
> 
> yum install -y "*ipa-server*" bind bind-dyndb-ldap ipa-server-install 
> --domain=example.com --realm=EXAMPLE.COM --setup-dns 
> --forwarder=192.168.1.1
> 
> But the installation wizard fails at:
> 
> Checking DNS forwarders, please wait ...
> ipa: ERROR   DNS server 192.168.1.1: query '. SOA': The DNS 
> operation timed out after 10.00124242 seconds
> ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 
> 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 
> seconds
> 
> 
> Is there some way I can better troubleshoot this? Can I increase the DNS 
> timeout (maybe it's simply slow via VirtualBox).

Please try command
$ dig @192.168.1.1 . SOA
and paste the output here.

Also, please run the installer again with option --debug.

I will have a look.

Thank you.

--
Petr^2 Spacek

--
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] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4

2016-02-19 Thread Lukas Slebodnik 
On (19/02/16 14:03), Harald Dunkel wrote:
>Hi folks,
>
>is it just me, or does sss_ssh_knownhostsproxy break
>
>   ssh -4 host.example.com
>
>?
>
>host.example.com has A and  entries in DNS, of course.
>If I comment out the line in ssh_config
>
># ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
>
>then I get the expected IPv4 connection. ???
>
>This is sssd 1.13.3-1, built and run on Debian Jessie.
>
It's known bug
https://fedorahosted.org/sssd/ticket/1498
https://bugzilla.redhat.com/show_bug.cgi?id=1063278

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] ID Views without AD

2016-02-19 Thread Sumit Bose 
On Fri, Feb 19, 2016 at 12:12:42PM +, Mike Kelly wrote:
> Ahha! I seem to have gotten somewhere now!
> 
> I just re-applied the view to my host, restarted sssd and cleared its

yes, that's what I meant earlier with the missing view entry in the
cache. SSSD tries to figure out if a view name changed at startup time
and if it happened it removes the old view data. This does not work
properly because of the  issue we have and hence SSSD needs some help by
either doing a fresh view name change with the fixed version or remove
the existing cache.

> cache, and it's now picking up my overridden UID and GID! (I had to
> manually add an entry for the overridden GID to /etc/group, because FreeIPA
> won't let me override the private user groups.)

yes, this is expected, but you do not have to add the group to
/etc/group but you can add a new group with the overridden GID to IPA as
well.

bye,
Sumit

(Alexander already commented on the questions below)

> 
> One odd caveat, but perhaps this is part of the design... if I do a `getent
> $IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user
> with the overridden UID. I'd expect the first one to just give no result?
> 
> 
> 
> One side question, though... now that I have done half of the work for an
> AD trust... is it possible for me to make my FreeIPA server into an AD
> controller for the one Windows box in my house? Some searching I did before
> indicated no, in part because Samba required Heimdal instead of MIT
> Kerberos... is that still true?
> 
> On Thu, Feb 18, 2016 at 12:21 PM Mike Kelly  wrote:
> 
> > Thanks for the quick reply.
> >
> > FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd
> > packages.
> >
> > I don't seem to have the "ldbadd" command on my client, either.
> >
> > Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and
> > I see more in the logs now.
> >
> > But, I don't seem to be seeing my UID changing like I'd expect, and I seem
> > to no longer be able to run sudo on my client...
> >
> > If I unapply the view from my client's host, though, sudo again works as
> > expected. So, it's picking up... something... just not quite everything yet.
> >
> >
> > On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose  wrote:
> >
> >> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote:
> >> > On Tue, Feb 16, 2016 at 04:23:10PM +, Mike Kelly wrote:
> >> > > >>  Thanks. Here's what is hopefully the relevant lines:
> >> > > >
> >> > > > I'm sorry, but these logs only capture how the original entry was
> >> > > searched, not the overrides. Can you capture the full logs since the
> >> sssd
> >> > > startup? Also please make sure the cache was invalidated prior to the
> >> > > request with sss_cache -E.
> >> > >
> >> > > Attached are the full logs since a restart of sssd.
> >> >
> >> > Thank you, the logs helped. The IPA client reads the idview at startup
> >> > time either from the cache or the IPA server. Since there is of course
> >> > no idview name saved in the cache of your client the name must be looked
> >> > up from the server. The lookup of the idview name is part of the request
> >> > which reads other data about the IPA domain and possible trusted
> >> > domains. Unfortunately the current code expects that e.g. the domain SID
> >> > of the IPA domain is defined before it proceeds to read the idview.
> >> >
> >> > This is of course a bug and I will try to fix it. If you would like to
> >> > try a work-around you can call ipa-adtrust-install on one of your IPA
> >> > servers. This will create the needed data on the server. It is
> >> > sufficient to call it on one server because the data will be replicated
> >> > to the other servers and since you currently not plan to add a trust to
> >> > a AD domain, you do not have to prepare additional services on other
> >> > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to
> >> > add a trust).
> >> >
> >> > If you can wait a day or two I'd be happy to prepare a SSSD test build
> >> > with a fix.
> >>
> >> It looks it was easier than I expected. You can find test packages for
> >> RHEL/CentOS-7 at
> >>
> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051
> >>
> >> (Please tell me if you need packages for a different platform)
> >>
> >> Before you upgrade the package on a client please run
> >>
> >> # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF
> >> dn: cn=views,cn=sysdb
> >> viewName: default
> >> EOF
> >>
> >> Otherwise SSSD will not recognise the name change and still show the
> >> original values. As an alternative you can remove the cache completely
> >> before starting the new version or unapply the idview and apply it again
> >> on the server while you restart the new sssd version on the client after
> >> each change on the server. I'll try to think of a way to make this more
> >> easy without breaking the existing detection of a change in the idview
> >>

[Freeipa-users] sssd 1.13.3: sss_ssh_knownhostsproxy seems to break ssh -4

2016-02-19 Thread Harald Dunkel 
Hi folks,

is it just me, or does sss_ssh_knownhostsproxy break

ssh -4 host.example.com

?

host.example.com has A and  entries in DNS, of course.
If I comment out the line in ssh_config

# ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

then I get the expected IPv4 connection. ???

This is sssd 1.13.3-1, built and run on Debian Jessie.


Every helpful comment is highly appreciated
Harri

-- 
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] DNS operation timed out when installing IPA with forwarders

2016-02-19 Thread Petr Spacek 
On 19.2.2016 13:50, Geselle Stijn wrote:
> Hello fellow FreeIPA users,
> 
> I'm trying to setup FreeIPA in a lab environment (VirtualBox):
> 
> 
> -  ad.example.com (Windows Server 2008 R2) - 192.168.1.1
> 
> -  ipa.example.com (CentOS 7.2) - 192.168.1.2
> Both machines can ping each other, DNS resolving works:
> 
> [root@ipa ~] nslookup ad
> Server: 192.168.1.1
> Address: 192.168.1.1#53
> 
> Name: ad.example.com
> Address: 192.168.1.1
> 
> 
> I executed:
> 
> yum install -y "*ipa-server*" bind bind-dyndb-ldap
> ipa-server-install --domain=example.com --realm=EXAMPLE.COM --setup-dns 
> --forwarder=192.168.1.1
> 
> But the installation wizard fails at:
> 
> Checking DNS forwarders, please wait ...
> ipa: ERROR   DNS server 192.168.1.1: query '. SOA': The DNS 
> operation timed out after 10.00124242 seconds
> ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 
> 192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 
> seconds
> 
> 
> Is there some way I can better troubleshoot this? Can I increase the DNS 
> timeout (maybe it's simply slow via VirtualBox).

Please try command
$ dig @192.168.1.1 . SOA
and paste the output here.

Also, please run the installer again with option --debug.

I will have a look.

Thank you.

-- 
Petr^2 Spacek

-- 
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] Incomplete user identities on legacy clients

2016-02-19 Thread Alexander Bokovoy 

On Fri, 19 Feb 2016, Vladimir Kondratyev wrote:

Hi

I installed latest ipa-server-4.2.0-15.el7_2.6.x86_64 with slapi-nis
plugin on RHEL7.2 than installed and configured
ipa-server-trust-ad-4.2.0-15.el7_2.6.x86_64 with compat-schema option
and than successfully established one-way trust with Win2008R2 domain
(named ad.dlink)

After that following objects have been created in AD:

groups:
"linux admins@ad.dlink"
"linux users@ad.dlink"

users:
"user2@ad.dlink" - member of "linux users@ad.dlink"
"user3@ad.dlink" - member of both "linux users@ad.dlink" and "linux 
admins@ad.dlink" groups

On IPA side i created following groups and relations:

external member -> external ipa group -> posix ipa group
"linux admins@ad.dlink" -> "ad_la_ext" -> "ad_la"
"linux users@ad.dlink" -> "ad_lu_ext" -> "ad_lu"

So "user2@ad.dlink" being logged in to ipa-client becomes a member of
"ad_lu" posix group and "user3@ad.dlink" becomes a member of both
"ad_la" and "ad_lu" groups

That is working like intended for sssd1.9+ clients but not for legacy
clients

Yes, there is a complex issue in SSSD and slapi-nis that prevents
AD members of IPA groups to be fully resolved for legacy clients.
A good thing is that it is now almost fixed and updates for sssd and
slapi-nis  will appear in next RHEL 7 update.

--
/ Alexander Bokovoy

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

[Freeipa-users] DNS operation timed out when installing IPA with forwarders

2016-02-19 Thread Geselle Stijn 
Hello fellow FreeIPA users,

I'm trying to setup FreeIPA in a lab environment (VirtualBox):


-  ad.example.com (Windows Server 2008 R2) - 192.168.1.1

-  ipa.example.com (CentOS 7.2) - 192.168.1.2
Both machines can ping each other, DNS resolving works:

[root@ipa ~] nslookup ad
Server: 192.168.1.1
Address: 192.168.1.1#53

Name: ad.example.com
Address: 192.168.1.1


I executed:

yum install -y "*ipa-server*" bind bind-dyndb-ldap
ipa-server-install --domain=example.com --realm=EXAMPLE.COM --setup-dns 
--forwarder=192.168.1.1

But the installation wizard fails at:

Checking DNS forwarders, please wait ...
ipa: ERROR   DNS server 192.168.1.1: query '. SOA': The DNS 
operation timed out after 10.00124242 seconds
ipa.ipapython.install.cli.install_tool(Server): ERROR DNS server 
192.168.1.1: query '. SOA': The DNS operation timed out after 10.00124242 
seconds


Is there some way I can better troubleshoot this? Can I increase the DNS 
timeout (maybe it's simply slow via VirtualBox).


Thank you!

-Stijn
-- 
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] Incomplete user identities on legacy clients

2016-02-19 Thread Vladimir Kondratyev 
Hi

I installed latest ipa-server-4.2.0-15.el7_2.6.x86_64 with slapi-nis plugin on 
RHEL7.2 than installed and configured  
ipa-server-trust-ad-4.2.0-15.el7_2.6.x86_64 with compat-schema option and than 
successfully established one-way trust with Win2008R2 domain (named ad.dlink) 

After that following objects have been created in AD:

groups:
"linux admins@ad.dlink"
"linux users@ad.dlink"

users:
"user2@ad.dlink" - member of "linux users@ad.dlink"
"user3@ad.dlink" - member of both "linux users@ad.dlink" and "linux 
admins@ad.dlink" groups

On IPA side i created following groups and relations:

external member -> external ipa group -> posix ipa group
"linux admins@ad.dlink" -> "ad_la_ext" -> "ad_la"
"linux users@ad.dlink" -> "ad_lu_ext" -> "ad_lu"

So "user2@ad.dlink" being logged in to ipa-client becomes a member of "ad_lu" 
posix group and "user3@ad.dlink" becomes a member of both "ad_la" and "ad_lu" 
groups

That is working like intended for sssd1.9+ clients but not for legacy clients

Steps for reproduce

1. Install RHEL5 (RHEL5.1 in my case but i tried another 5.x also)
2. Run ipa-advise config-redhat-nss-ldap on ipa trust-controller
3. login to RHEL5 as root and configure it with shell script obtained on step 2
4. reset compat ldap cache with issuing "systemctl restart dirsrv.target" on 
ipa-server (trust controller)
5. print user identities (or just login as user) on legacy client in following 
order: user2@ad.dlink than user3@ad.dlink
[root@rhel51 ~]# id user2@ad.dlink
uid=1777801107(user2@ad.dlink) gid=1777801107(user2@ad.dlink) 
groups=1777801107(user2@ad.dlink),12003(ad_lu),1777801104(linux 
users@ad.dlink),1777800513(domain users@ad.dlink) 
context=root:system_r:unconfined_t:SystemLow-SystemHigh
[root@rhel51 ~]# id user3@ad.dlink
uid=1777801108(user3@ad.dlink) gid=1777801108(user3@ad.dlink) 
groups=1777801108(user3@ad.dlink),12003(ad_lu),1777801104(linux 
users@ad.dlink),1777800513(domain users@ad.dlink) 
context=root:system_r:unconfined_t:SystemLow-SystemHigh

As you can see "user3@ad.dlink" misses "ad_la" and "linux admins@ad.dlink" 
groups membership!

Now reset compat ldap cache with "systemctl restart dirsrv.target" again and 
print identities on legacy client in opposite order: user3@ad.dlink than 
user2@ad.dlink
[root@rhel51 ~]# id user3@ad.dlink
uid=1777801108(user3@ad.dlink) gid=1777801108(user3@ad.dlink) 
groups=1777801108(user3@ad.dlink),12003(ad_lu),12004(ad_la),1777801104(linux
 users@ad.dlink),1777801105(linux admins@ad.dlink),1777800513(domain 
users@ad.dlink) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[root@rhel51 ~]# id user2@ad.dlink
uid=1777801107(user2@ad.dlink) gid=1777801107(user2@ad.dlink) 
groups=1777801107(user2@ad.dlink),12003(ad_lu),1777801104(linux 
users@ad.dlink),1777800513(domain users@ad.dlink) 
context=root:system_r:unconfined_t:SystemLow-SystemHigh

Voila, "user3@ad.dlink" is a "ad_la" and "linux admins@ad.dlink" groups member 
now!

So it seems external member -> posix ipa group relations are cached for first 
user logged (or issued id command) into legacy client after compat-cache reset 
and these relations are not updated on other user login

Also its interesting that 2 objects with the same dn but different objectClass, 
memberUid and ipaAnchorUUID can be found in compat ldap after first login or 
executing of id

[root@idm1 ~]# ldapsearch -Wx -D "cn=Directory manager" -b 
"cn=ad_lu,cn=groups,cn=compat,dc=ipa,dc=dlink"
Enter LDAP Password: 
# extended LDIF
#
# LDAPv3
# base

Re: [Freeipa-users] ID Views without AD

2016-02-19 Thread Mike Kelly 
Thanks.

Ok, one final concern, though, I guess I didn't resolve the issues with
sudo...

[root@data ~]# sudo -l -U pioto
User pioto is not allowed to run sudo on data.

But, huh, after running these few commands, now I can?

[root@data ~]# id pioto
uid=1001(pioto) gid=1001(pioto)
groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),140340
[root@data ~]# getent passwd 140340
admin:*:140340:140340:Administrator:/home/admin:/bin/bash
[root@data ~]# getent passwd admin
admin:*:140340:140340:Administrator:/home/admin:/bin/bash
[root@data ~]# id pioto
uid=1001(pioto) gid=1001(pioto)
groups=1001(pioto),991(libvirt),988(docker),1005(backups),1009(media),140340(admins)
[root@data ~]# sudo -l -U pioto
Matching Defaults entries for pioto on this host:
requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR
LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS
LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION
LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC
LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User pioto may run the following commands on this host:
(ALL : ALL) ALL
[root@data ~]# getent group 140340
admins:*:140340:admin,pioto



Is there maybe some other cache that `sss_cache -E` isn't clearing? Or some
other reason it didn't properly fetch the "admins" group until I looked up
the "admin" user?


On Fri, Feb 19, 2016 at 7:20 AM Alexander Bokovoy 
wrote:

> On Fri, 19 Feb 2016, Mike Kelly wrote:
> >Ahha! I seem to have gotten somewhere now!
> >
> >I just re-applied the view to my host, restarted sssd and cleared its
> >cache, and it's now picking up my overridden UID and GID! (I had to
> >manually add an entry for the overridden GID to /etc/group, because
> FreeIPA
> >won't let me override the private user groups.)
> >
> >One odd caveat, but perhaps this is part of the design... if I do a
> `getent
> >$IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user
> >with the overridden UID. I'd expect the first one to just give no result?
> That's by design.
>
> >
> >One side question, though... now that I have done half of the work for an
> >AD trust... is it possible for me to make my FreeIPA server into an AD
> >controller for the one Windows box in my house? Some searching I did
> before
> >indicated no, in part because Samba required Heimdal instead of MIT
> >Kerberos... is that still true?
> Yes and no. FreeIPA cannot be made an AD controller and even when we
> complete porting Samba AD to use MIT Kerberos, that will not change as
> Samba AD is using its own, completely separate, data store and cannot be
> made using an external LDAP server for that. Samba AD is a special mode
> in Samba, different from a traditional domain controller mode used by
> FreeIPA.
>
> So while you are able to join your Windows machine to Samba AD with
> Heimdal now or with MIT Kerberos in future, this will be a join to a
> totally separate domain.
>
>
> --
> / Alexander Bokovoy
>
-- 

Mike Kelly
-- 
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] ID Views without AD

2016-02-19 Thread Alexander Bokovoy 

On Fri, 19 Feb 2016, Mike Kelly wrote:

Ahha! I seem to have gotten somewhere now!

I just re-applied the view to my host, restarted sssd and cleared its
cache, and it's now picking up my overridden UID and GID! (I had to
manually add an entry for the overridden GID to /etc/group, because FreeIPA
won't let me override the private user groups.)

One odd caveat, but perhaps this is part of the design... if I do a `getent
$IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user
with the overridden UID. I'd expect the first one to just give no result?

That's by design.



One side question, though... now that I have done half of the work for an
AD trust... is it possible for me to make my FreeIPA server into an AD
controller for the one Windows box in my house? Some searching I did before
indicated no, in part because Samba required Heimdal instead of MIT
Kerberos... is that still true?

Yes and no. FreeIPA cannot be made an AD controller and even when we
complete porting Samba AD to use MIT Kerberos, that will not change as
Samba AD is using its own, completely separate, data store and cannot be
made using an external LDAP server for that. Samba AD is a special mode
in Samba, different from a traditional domain controller mode used by
FreeIPA.

So while you are able to join your Windows machine to Samba AD with
Heimdal now or with MIT Kerberos in future, this will be a join to a
totally separate domain.


--
/ Alexander Bokovoy

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

Re: [Freeipa-users] ID Views without AD

2016-02-19 Thread Mike Kelly 
Ahha! I seem to have gotten somewhere now!

I just re-applied the view to my host, restarted sssd and cleared its
cache, and it's now picking up my overridden UID and GID! (I had to
manually add an entry for the overridden GID to /etc/group, because FreeIPA
won't let me override the private user groups.)

One odd caveat, but perhaps this is part of the design... if I do a `getent
$IPA_UID` or `getent $OVERRIDE_UID`... both give the same output, my user
with the overridden UID. I'd expect the first one to just give no result?



One side question, though... now that I have done half of the work for an
AD trust... is it possible for me to make my FreeIPA server into an AD
controller for the one Windows box in my house? Some searching I did before
indicated no, in part because Samba required Heimdal instead of MIT
Kerberos... is that still true?

On Thu, Feb 18, 2016 at 12:21 PM Mike Kelly  wrote:

> Thanks for the quick reply.
>
> FWIW, I'm on CentOS 7, but I haven't yet tried to apply your test sssd
> packages.
>
> I don't seem to have the "ldbadd" command on my client, either.
>
> Also, I tried running `sudo ipa-adtrust-install --add-sids -A pioto`, and
> I see more in the logs now.
>
> But, I don't seem to be seeing my UID changing like I'd expect, and I seem
> to no longer be able to run sudo on my client...
>
> If I unapply the view from my client's host, though, sudo again works as
> expected. So, it's picking up... something... just not quite everything yet.
>
>
> On Thu, Feb 18, 2016 at 10:28 AM Sumit Bose  wrote:
>
>> On Thu, Feb 18, 2016 at 11:26:58AM +0100, Sumit Bose wrote:
>> > On Tue, Feb 16, 2016 at 04:23:10PM +, Mike Kelly wrote:
>> > > >>  Thanks. Here's what is hopefully the relevant lines:
>> > > >
>> > > > I'm sorry, but these logs only capture how the original entry was
>> > > searched, not the overrides. Can you capture the full logs since the
>> sssd
>> > > startup? Also please make sure the cache was invalidated prior to the
>> > > request with sss_cache -E.
>> > >
>> > > Attached are the full logs since a restart of sssd.
>> >
>> > Thank you, the logs helped. The IPA client reads the idview at startup
>> > time either from the cache or the IPA server. Since there is of course
>> > no idview name saved in the cache of your client the name must be looked
>> > up from the server. The lookup of the idview name is part of the request
>> > which reads other data about the IPA domain and possible trusted
>> > domains. Unfortunately the current code expects that e.g. the domain SID
>> > of the IPA domain is defined before it proceeds to read the idview.
>> >
>> > This is of course a bug and I will try to fix it. If you would like to
>> > try a work-around you can call ipa-adtrust-install on one of your IPA
>> > servers. This will create the needed data on the server. It is
>> > sufficient to call it on one server because the data will be replicated
>> > to the other servers and since you currently not plan to add a trust to
>> > a AD domain, you do not have to prepare additional services on other
>> > server (with FreeIPA-4.2 this wouldn't even be necessary if you plan to
>> > add a trust).
>> >
>> > If you can wait a day or two I'd be happy to prepare a SSSD test build
>> > with a fix.
>>
>> It looks it was easier than I expected. You can find test packages for
>> RHEL/CentOS-7 at
>>
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=13035051
>>
>> (Please tell me if you need packages for a different platform)
>>
>> Before you upgrade the package on a client please run
>>
>> # ldbadd -H /var/lib/sss/db/cache_your.domain.name.ldb << EOF
>> dn: cn=views,cn=sysdb
>> viewName: default
>> EOF
>>
>> Otherwise SSSD will not recognise the name change and still show the
>> original values. As an alternative you can remove the cache completely
>> before starting the new version or unapply the idview and apply it again
>> on the server while you restart the new sssd version on the client after
>> each change on the server. I'll try to think of a way to make this more
>> easy without breaking the existing detection of a change in the idview
>> name.
>>
>> HTH
>>
>> bye,
>> Sumit
>>
>> >
>> > bye,
>> > Sumit
>> >
>> > >
>> > > I ran these commands:
>> > >
>> > > systemctl stop sssd
>> > >
>> > > echo 'MARK' >> /var/log/sssd/sssd_home.pioto.org.log # so I
>> could
>> > > mark were the restart happened
>> > >
>> > > sss_cache -E
>> > >
>> > > systemctl start sssd
>> > >
>> > > sss_cache -E
>> > >
>> > > id pioto
>> > >
>> > > 
>> > >
>> > > I still don't see the override being applied. Possibly because of
>> this line?
>> > >
>> > > (Tue Feb 16 11:12:27 2016) [sssd[be[home.pioto.org]]]
>> > > [ipa_get_ad_override_send]
>> > > (0x4000): View not defined, nothing to do.
>> > >
>> > > So, I get the feeling that, for whatever reason, sssd isn't correctly
>> > > deciding that my id view applies to this host, or just isn't looking
>> it up?
>> > >
>> >

Re: [Freeipa-users] freeipa permission denied for user

2016-02-19 Thread Rakesh Rajasekharan 
>>Actually, it should be 1777

> sh$ ls -ld /tmp/
> drwxrwxrwt. 11 root root 260 Feb 19 10:27 /tmp/
 ^
  >   This is important.>

yes, I have now corrected them... Thanks...



On Fri, Feb 19, 2016 at 2:59 PM, Lukas Slebodnik 
wrote:

> On (19/02/16 14:54), Rakesh Rajasekharan wrote:
> >>
> >>This usually mean critical error in sssd.
> >> Please provide log files (sssd_$domain.log and krb5_child.log)
> >
> >I found this in my sssd-$domain.log
> >
> > [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user
> >[tempuser] found
> >
> >so searching around I found that the permissions for the /tmp directory
> >should be 777..
> >
> >setting it to 777 fixed the issue for me..
> >
> Actually, it should be 1777
>
> sh$ ls -ld /tmp/
> drwxrwxrwt. 11 root root 260 Feb 19 10:27 /tmp/
>  ^
> This is important.
>
> 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] About ipa passwd and kpasswd

2016-02-19 Thread Petr Vobornik 

On 02/18/2016 04:46 PM, bahan w wrote:

Hello everyone.

I send you this mail because I have sometimes a problem when using ipa
passwd to generate a One Time Password and then using kpasswd to set a
strong random password using a password policy.

When I perform the ipa passwd command and just after the kpasswd command, I
got an error message.

Here is the command (I have an admin TGT) :
echo "onetimepwd\nonetimepwd\n" | ipa passwd ; echo
"onetimepwd\n\n\n" | kpasswd 

And here is the result :
###
--
Changed password for "@"
--
Password for @:
kpasswd: Preauthentication failed getting initial ticket
###

When I perform a sleep 5, then the sucession of these commands complete
successfully.
I tried to sleep 1s or 2s, but sometimes I got the error message, and
sometimes not.
So I extended the sleep duration to 5s.

I was wondering if it was normal behaviour from ipa-server/client 3.0.0-47 ?

If yes, do you know what the minimum duration in seconds that I have to
wait after setting a one time password before setting a more definitive
password (a password respecting the password policy) ?

Best regards.

Bahan





Following works for me:

ADMINPW=Secret123
TEMPPW=temppwd
FINALPW=Secret1234
TESTUSER=fbar
kdestroy -A
echo -e "${ADMINPW}" | kinit admin
klist
echo -e "${TEMPPW}\n${TEMPPW}\n" | ipa passwd $TESTUSER
echo -e "${TEMPPW}\n${FINALPW}\n${FINALPW}\n" | kpasswd $TESTUSER
klist
kdestroy -A
echo -e "${FINALPW}" | kinit $TESTUSER
klist
kdestroy -A


also works if kpasswd is changed to kinit.

You can also try to use KRB5_TRACE=/dev/stdout to debug it:
  # KRB5_TRACE=/dev/stdout kpasswd user

--
Petr Vobornik

--
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 permission denied for user

2016-02-19 Thread Lukas Slebodnik 
On (19/02/16 14:54), Rakesh Rajasekharan wrote:
>>
>>This usually mean critical error in sssd.
>> Please provide log files (sssd_$domain.log and krb5_child.log)
>
>I found this in my sssd-$domain.log
>
> [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user
>[tempuser] found
>
>so searching around I found that the permissions for the /tmp directory
>should be 777..
>
>setting it to 777 fixed the issue for me..
>
Actually, it should be 1777

sh$ ls -ld /tmp/
drwxrwxrwt. 11 root root 260 Feb 19 10:27 /tmp/
 ^
This is important.

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] freeipa permission denied for user

2016-02-19 Thread Rakesh Rajasekharan 
>
>This usually mean critical error in sssd.
> Please provide log files (sssd_$domain.log and krb5_child.log)

I found this in my sssd-$domain.log

 [krb5_auth_prepare_ccache_name] (0x1000): No ccache file for user
[tempuser] found

so searching around I found that the permissions for the /tmp directory
should be 777..

setting it to 777 fixed the issue for me..



Thanks,
Rakesh



On Fri, Feb 19, 2016 at 1:08 PM, Lukas Slebodnik 
wrote:

> On (18/02/16 18:41), Rakesh Rajasekharan wrote:
> >I set up freeipa on our environment and its works perfectly for most of
> the
> >hosts.. but on few I am getting a permission denied.
> >
> >[root@ipa-client-1c :~] ssh tempuser@localhost
> >tempuser@localhost's password:
> >Permission denied, please try again.
> >tempuser@localhost's password:
> >
> >
> >
> >
> >I checked the hbac, but that seems to be fine
> >
> >root@ipa-master-test-1b ] ipa hbactest --user=tempuser --host=x.x.x.x
> >--service=sshd
> >
> >Access granted: True
> >
> >  Matched rules: allow_all
> >
> >
> >Another thing I noticed is the nsswitch.conf had the below entries after
> >the freeipa installation
> >passwd: files sss ldap
> >shadow: files sss ldap
> >group:  files sss ldap
> >
> >hosts:  files dns
> >
> >
> >bootparams: nisplus [NOTFOUND=return] files
> >
> >ethers: files
> >netmasks:   files
> >networks:   files
> >protocols:  files
> >rpc:files
> >services:   files sss
> >
> >netgroup:   files sss ldap
> >
> >publickey:  nisplus
> >
> >automount:  files ldap
> >aliases:files nisplus
> >
> >sudoers: files sss
> >
> >
> >The ldap shouldn't be there above I guess..
> >
> >and from the logs, i have the below errors
> >
> >==> /var/log/secure <==
> >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_unix(sshd:auth):
> authentication
> >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x  user=tempuser
> >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): authentication
> >failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=tempuser
> >Feb 18 03:29:33 ip-x-x-x-x sshd[24851]: pam_sss(sshd:auth): received for
> >user tempuser: 4 (System error)
> 
> This usually mean critical error in sssd.
> Please provide log files (sssd_$domain.log and krb5_child.log)
> with high debug level.
> https://fedorahosted.org/sssd/wiki/Troubleshooting
>
> Whis version of sssd do you have?
>
> 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] Split backup actions in stop - backup - start commands

2016-02-19 Thread Matt . 
Hi guys,

As I'm using burp for backup I get the feeling it fails obt eh
ipa-backup proces itself when runned as a pre_script. I think it waits
for some exitcode or already gets it before the real backup of IPA has
been finished.

I'm checking this out as burp also outputs messages as errors because
it just does it that way.



2016-02-18 16:08 GMT+01:00 Rob Crittenden :
> David Kupka wrote:
>> On 17/02/16 10:47, Matt . wrote:
>>> Hi David,
>>>
>>> I have tested your way out and it seems to be OK.
>>>
>>> The reason why I need this was is so I can perform a stop and
>>> ipa-backup before I start my backup to my backupserver. (pre-command).
>>>
>>> If I use ipa-backup directly it errors between the stop of ipa and the
>>> actual ipa backup. I need to check that out further.
>>>
>>> An ipactl start is not needed it seems as the ipa-backup command seems
>>> to start ipa at any time again.
>>>
>>> Do you understand/agree here ?
>>
>> Hello Matt,
>>
>> unfortunately I don't understand. The backup procedure AFAIK should work
>> like this:
>>
>> # ipa-backup && rsync -r /var/lib/ipa/backup/ backup.example.test:/ipa/
>>
>> You ca run it manually or place it into the crontab or use it in your
>> orchestration system.
>> It will backup the ipa server with necessary stop and start and then
>> copy the new backup to the backup server.
>>
>> Still I don't see the need for stopping the server manually.
>>
>> ipa-backup calls "ipactl start" [0]. If you remove the else branch it
>> will not start the server.
>>
>> [0
>> ]https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316
>
> I've also been wondering about the request to remove the stop/start. The
> stop should be idempotent. Is an error being thrown?
>
> 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] FreeIPA -> FreeIPA trusts

2016-02-19 Thread Chris Addie 
I have two separate networks each with their own FreeIPA server(s) and I
would like for users from network A to be able to be able to access services
in network B, but not the other way around. The documentation for ipa
trust-add seems to imply this is not possibly however as “Only trusts to
Active Directory domains are supported right now.” It seems really odd that
FreeIPA supports trusting a Windows AD domain but not another FreeIPA
domain. Is this really the case? If so are IPA -> IPA trusts a feature that
is planned for the future? Is there some other way I could achieve this?

 

Thanks,

 

Chris Addie

Señor Security Engineer

Datacom Technical Security Services Pty Ltd | A.B.N. 84 151 241 253

Mb: +61 421 138 786 | eM:  
chris.ad...@datacom.com.au

 

Discreet | Niche | Tailored

 


# Confidentiality and Privilege Notice This document is intended
solely for the named addressee. The information contained in the pages is
confidential and contains legally privileged information. If you are not the
addressee indicated in this message or responsible for delivery of the
message to such person, you may not copy or deliver this message to anyone,
and you should destroy this message and kindly notify the sender by reply
email. Confidentiality and legal privilege are not waived or lost by reason
of mistaken delivery to you.

#

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
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