[Freeipa-users] Re: Failed Upgrade?

2017-08-09 Thread Ian Harding via FreeIPA-users 

On 8/9/17 3:05 AM, thierry bordaz wrote:


Hi Ian,

Thanks for having gather those data.

#
# So pkidbuser entries have a same (old) userCertificate likely
generated during install
# But only freeipa-sea has a new one created on freeipa-sea around
Jun 8th 2017 05:54:16
# This recent certificate is identified by 5938e68800010429
#
[root@freeipa-sea ianh]# ldapsearch -LLL -D 'cn=directory manager'
-W -b "uid=pkidbuser,ou=people,o=ipaca" nscpentrywsi
dn: uid=pkidbuser,ou=people,o=ipaca
...
nscpentrywsi: userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MR 
nscpentrywsi: userCertificate;vucsn-5938e68800010429::
MIIDbjCCAlagAwIBAgI 

[root@seattlenfs ianh]# ldapsearch -LLL -D 'cn=directory manager'
-W -b uid=pkidbuser,ou=people,o=ipaca nscpentrywsi
dn: uid=pkidbuser,ou=people,o=ipaca
nscpentrywsi: userCertificate::
MIIDczCCAlugAwIBAgIBBDANBgkqhkiG9w0BAQsFADA0MR 



#
# why 5938e68800010429 value was not propagated to seattlenfs ?
# The most recent update (from freeipa-sea) that was replicated to
seattlenfs
# is  1 year old (57be804300070429 - Aug 25th 2016 05:21:07).
# In addition seattlenfs received direct update (last one was in
Jan 1017) that were not
# replicated to freeipa-sea
#
# The two servers have diverged because they can not replicate to
eachother because
# they were not correctly initialize.
# They have different "replicageneration" (57c291d90429 vs
55c8f3ae0060)
#
# It is looking like freeipa-sea was created one or two years ago
and used to initialized seattlenfs.
# But later freeipa-sea was recreated.


That's about right.


#
[root@freeipa-sea ianh]# ldapsearch -LLL -D 'cn=directory manager'
-W -b "o=ipaca"

"(&(objectclass=nstombstone)(nsUniqueId=---))"
Enter LDAP Password:
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds50ruv: {replicageneration} 57c291d90429
nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57f840bf0429 598a1c410429
nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389}
nsruvReplicaLastModified: {replica 1065
ldap://freeipa-sea.bpt.rocks:389} 598a1c16
nsruvReplicaLastModified: {replica 1290
ldap://seattlenfs.bpt.rocks:389} 

[root@seattlenfs ianh]# ldapsearch -LLL -D 'cn=directory manager'
-W -b "o=ipaca"

"(&(objectclass=nstombstone)(nsUniqueId=---))"
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsds50ruv: {replicageneration} 55c8f3ae0060
nsds50ruv: {replica 1065 ldap://freeipa-sea.bpt.rocks:389}
57b103d40429 57be804300070429
nsds50ruv: {replica 1290 ldap://seattlenfs.bpt.rocks:389}
57be804c050a 58723615050a
nsruvReplicaLastModified: {replica 1290
ldap://seattlenfs.bpt.rocks:389} 
nsruvReplicaLastModified: {replica 1065
ldap://freeipa-sea.bpt.rocks:389} 



In conclusion:
From replication pov, the two instances can not communicate.
One solution would be to identify which instance is the good one, 
you want to keep.

and reinit the second one from that reference.


What exactly does reinit mean?  I have run

ipa-replica-manage re-initialize --from freeipa-sea.bpt.rocks

several times over the years when replication has stopped.

Replication actually is working, as far as user and machine accounts and 
attributes are concerned anyway, and has been for a while.


There is a zombie server freeipa-dal.bpt.rocks that I can't get rid 
of... it shows up in the GUI on the Topology page but generates a Server 
not found error.  I don't know if that's related.


On 08/08/2017 10:33 PM, Ian Harding via FreeIPA-users wrote:


On 8/7/17 1:44 AM, thierry bordaz wrote:




On 08/07/2017 09:22 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

On 08/04/2017 11:02 PM, Ian Harding via FreeIPA-users wrote:

On 8/4/17 2:16 AM, Florence Blanc-Renaud wrote:


On 08/03/2017 11:13 PM, Ian Harding via FreeIPA-users wrote:

On 08/03/2017 12:28 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 11:51 PM, Ian Harding via FreeIPA-users wrote:

On 08/02/2017 12:11 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 01:43 AM, Ian Harding wrote:

On 08/01/2017 12:03 PM, Rob Crittenden wrote:

Ian Harding wrote:

On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 03:11 PM, Ian Harding wrote:

On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:
On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users 
wrote:



On 07/31/2017 11:34 AM, Rob Crittenden wrote:

Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that 
had apparently had
updates run but had not been restarted. ipactl says 
pki-tomcatd

would
not start.

Strangely, the actual service appears to be running:



dogtag is an

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Rob Crittenden via FreeIPA-users 
Michael Gusek wrote:
> Hello Rob,
> 
> i can understand why CA won't start with expired certs. Actually my
> system date is a day before expiring (expiring date is 30 Jul 2017,
> system date now 29 Jul 2017), but CA won't start. How to "ensure that
> the CA comes up" ?

Ok, well the logs I responded to were from [07/Aug/2017:14:21:41].

ipactl is going to restart ntpd which would revert the time.

What I'd try is:

- ipactl stop
- service ntpd stop (to be sure)
- date 
- service pki-tomcatd@pki-tomcat.service start

To see if the CA came up:

curl http://`hostname`:8080/ca/ee/ca/getCertChain

If so then service certmonger restart

rob

> 
> Michael
> 
> 
> Am 08.08.2017 um 17:40 schrieb Rob Crittenden:
>> Michael Gusek via FreeIPA-users wrote:
>>> Hi Fraser,
>>>
>>> at the moment, i can't provide this logfile, i've moved that back to
>>> have only new log lines. But a new new logfile is not created ??? In my
>>> old logfile i have some lines after switch to basic auth, but before
>>> setting time to past:
>>>
>> The CA won't start with expired certs.
>>
>> I'd set the time back to the past and ensure that the CA comes up. The
>> debug log in that case should tell you what is going on. Be sure that
>> ntpd is stopped.
>>
>> Restarting certmonger should be sufficient to have it try renewal as it
>> will see on startup that the certs need to be refreshed.
>>
>> rob
> 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Show AD groups members from command line

2017-08-09 Thread Jakub Hrozek via FreeIPA-users 

> On 9 Aug 2017, at 17:21, Steve Weeks via FreeIPA-users 
>  wrote:
> 
> I can use 'id ad_user@ad_domain' command to see what groups an ad_user is a 
> member of.
> 
> Is there a way from the Linux command line to see who are the member of 
> some_ad_group@ad_domain are?
> 

getent group some_ad_group@ad_domain

But please note that the getent group output is not guaranteed to be 100% 
correct. For starters, sssd has a limit on how many nesting levels it would 
traverse, so if a member you’re looking for is very deep in the nesting 
hierarchy, it won’t be displayed (unless you tune the nesting limit..)

> Thanks,
> Steve
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Cannot access Web UI after IPA upgrade to 4.5

2017-08-09 Thread Gustavo Berman via FreeIPA-users 
Hi Pavel,
On this machine it says that the first install of rhel-release-server was
7.2-9
But the ipa information came from a centos 6.4 install some years ago with
ipa 3.0
Later it was converted to rhel 7.0  and then upgraded through the years
Hope that helps


On Wed, Aug 9, 2017 at 12:15 PM, Pavel Vomacka  wrote:

>
>
> On 08/08/2017 02:03 PM, Gustavo Berman via FreeIPA-users wrote:
>
> Pavel,
> Thanks for the help, that solved the problem. Now I can access the web ui.
>
> I'm glad that it works again.
>
> The upgrade took place yesterday and it was a release upgrade from rhel
> 7.3 (last update was last week) to rhel 7.4 (so we had a lot of package
> updates):
>
> Thank you for info. I have one additional question: What was the first
> y-version of RHEL 7 you used?
>
> ID | Command line | Date and time| Action(s)  |
> Altered
> 
> ---
> 35 | update   | 2017-08-07 09:07 | E, I, O, U |
> 470 EE
>
>
> Acording to yum history info, this are the ipa packages that where updated:
> Obsoleted   ipa-admintools-4.4.0-14.el7_3.
> 7.noarch@rhel7
> Updated ipa-client-4.4.0-14.el7_3.7.x86_64
> @rhel7
> Obsoleting  ipa-client-4.5.0-21.el7.x86_64
> @rhel7
> Updated ipa-client-common-4.4.0-14.el7_3.7.noarch
> @rhel7
> Update4.5.0-21.el7.noarch
> @rhel7
> Updated ipa-common-4.4.0-14.el7_3.7.noarch
> @rhel7
> Update 4.5.0-21.el7.noarch
> @rhel7
> Updated ipa-python-compat-4.4.0-14.el7_3.7.noarch
> @rhel7
> Update4.5.0-21.el7.noarch
> @rhel7
> Updated ipa-server-4.4.0-14.el7_3.7.x86_64
> @rhel7
> Update 4.5.0-21.el7.x86_64
> @rhel7
> Updated ipa-server-common-4.4.0-14.el7_3.7.noarch
> @rhel7
> Update4.5.0-21.el7.noarch
> @rhel7
> Updated ipa-server-dns-4.4.0-14.el7_3.
> 7.noarch@rhel7
> Update 4.5.0-21.el7.noarch
> @rhel7
> Updated libipa_hbac-1.14.0-43.el7_3.18.x86_64
> @rhel7
> Update  1.15.2-50.el7.x86_64
> @rhel7
> Updated python-libipa_hbac-1.14.0-43.
> el7_3.18.x86_64  @rhel7
> Update 1.15.2-50.el7.x86_64
> @rhel7
> Updated python2-ipaclient-4.4.0-14.el7_3.7.noarch
> @rhel7
> Update4.5.0-21.el7.noarch
> @rhel7
> Updated python2-ipalib-4.4.0-14.el7_3.
> 7.noarch@rhel7
> Update 4.5.0-21.el7.noarch
> @rhel7
> Updated python2-ipaserver-4.4.0-14.el7_3.7.noarch
> @rhel7
> Update4.5.0-21.el7.noarch
> @rhel7
> Updated sssd-ipa-1.14.0-43.el7_3.18.x86_64
> @rhel7
> Update   1.15.2-50.el7.x86_64
> @rhel7
>
>
> Again, thanks for the help!
> Kind regards
>
>
> On Tue, Aug 8, 2017 at 5:51 AM, Pavel Vomacka  wrote:
>
>>
>>
>> On 08/07/2017 07:01 PM, Gustavo Berman via FreeIPA-users wrote:
>>
>> Hello Pavel
>>
>> On Mon, Aug 7, 2017 at 12:40 PM, Pavel Vomacka 
>> wrote:
>>
>>>
>>> Hello Gustavo,
>>> From what I can see, the issue would be PROTOCOL ERROR in whoami
>>> command. Could you please check whether all services running? Please run
>>> # ipactl status
>>>
>>> and post the output.
>>>
>>>
>> # ipactl status
>> Directory Service: RUNNING
>> krb5kdc Service: RUNNING
>> kadmin Service: RUNNING
>> named Service: RUNNING
>> httpd Service: RUNNING
>> ipa-custodia Service: RUNNING
>> pki-tomcatd Service: RUNNING
>> ipa-otpd Service: RUNNING
>> ipa-dnskeysyncd Service: RUNNING
>> ipa: INFO: The ipactl command was successful
>>
>>
>>
>>
>>> And please could you send me the /etc/named.conf? Especially everything
>>> after
>>>  dyndb "ipa"
>>> line is interesting for us.
>>>
>>
>> This is from /etc/named.conf
>>
>> options {
>> // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
>> listen-on-v6 {any;};
>>
>> // Put files that named is allowed to write in the data/
>> directory:
>> directory "/var/named"; // the default
>> dump-file   "data/cache_dump.db";
>> statistics-file "data/named_stats.txt";
>> memstatistics-file  "data/named_mem_stats.txt";
>>
>> forward only;
>> forwarders {
>> 10.73.2.100;
>> 10.73.2.102;
>> 10.73.2.101;
>> };
>>
>> // Any host is permitted to issue recursive queries
>> allow-recursion { any; };
>>
>> tkey-gssapi-keytab "/etc/named.keytab";
>> pid-file "/run/named/named.pid";
>> dnssec-enable yes;
>> dnssec-validation no;
>> bindkeys-file "/etc/named.iscdlv.key";
>> managed-keys-directory "/var/named/dynamic";
>> };

[Freeipa-users] Re: password reset privileges

2017-08-09 Thread Tiemen Ruiten via FreeIPA-users 
Hello,

Sorry for the late reply. This is the latest FreeIPA version in CentOS 7.3
(4.4.0-14).

Indeed the helpdesk role should be sufficient. I tried with the User
Administrator role as well, but that made no difference. Since it's working
for you, it's likely a config error, but I have no idea where to look at
this point. Do you have any pointers?

On 4 August 2017 at 19:19, Rob Crittenden  wrote:

> Tiemen Ruiten via FreeIPA-users wrote:
> > As I mentioned in my first mail, that doesn't work. For testing, I
> > created a new role that contains the following privileges:
> >
> > Group Administrators
> > Modify Group membership
> > Modify Users and Reset passwords
> > User Administrators
> >
> > Unfortunately, I get the same error.
>
> What version of IPA is this? The helpdesk role should be sufficient (and
> works for me).
>
> rob
>
> >
> > On 4 August 2017 at 17:40, Bob Rentschler  > > wrote:
> >
> > Assigning roles to your userwill fix that issue. The existing "User
> > Administrator" role may fit your needs, but I am unsure how
> restrictive
> > you want to be with permissions.
> >
> >
> > If you want to be more restrictive a custom role with "System:
> > Change User password" permissions would seem to be the right way.
> >
> > Make a privilege that contains only that permission (and and other
> > missing permissions down the road) add it to a new role and then
> > assign that role to your user.
> >
> >
> > Bob
> >
> > On Fri, Aug 4, 2017 at 10:12 AM, Tiemen Ruiten via FreeIPA-users
> >  > > wrote:
> >
> > Hello,
> >
> > I setup an LDAP User Federation in Keycloak to our FreeIPA
> > domain. Unfortunately, the password reset functionality appears
> > to only work when the user Keycloak binds as is in the admins
> > group. I tried both the User Administrator and helpdesk roles,
> > but always got this error:
> >
> > Caused by: javax.naming.NoPermissionException: [LDAP: error code
> > 50 - Insufficient 'write' privilege to the 'userPassword'
> > attribute of entry
> > 'uid=x,cn=users,cn=accounts,dc=example,dc=com'
> >
> > Is there a way to allow password resets without adding the
> > keycloak bind user to the admins group?
> >
> >
> > --
> > Tiemen Ruiten
> > Systems Engineer
> > R Media
> >
> > ___
> > FreeIPA-users mailing list --
> > freeipa-users@lists.fedorahosted.org
> > 
> > To unsubscribe send an email to
> > freeipa-users-le...@lists.fedorahosted.org
> > 
> >
> >
> >
> >
> >
> > --
> > Tiemen Ruiten
> > Systems Engineer
> > R Media
> >
> >
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave@lists.
> fedorahosted.org
> >
>
>


-- 
Tiemen Ruiten
Systems Engineer
R Media
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Show AD groups members from command line

2017-08-09 Thread Steve Weeks via FreeIPA-users 
I can use 'id ad_user@ad_domain' command to see what groups an ad_user is a
member of.

Is there a way from the Linux command line to see who are the member of
some_ad_group@ad_domain are?

Thanks,
Steve
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Cannot access Web UI after IPA upgrade to 4.5

2017-08-09 Thread Pavel Vomacka via FreeIPA-users 



On 08/08/2017 02:03 PM, Gustavo Berman via FreeIPA-users wrote:

Pavel,
Thanks for the help, that solved the problem. Now I can access the web ui.

I'm glad that it works again.
The upgrade took place yesterday and it was a release upgrade from 
rhel 7.3 (last update was last week) to rhel 7.4 (so we had a lot of 
package updates):


Thank you for info. I have one additional question: What was the first 
y-version of RHEL 7 you used?


ID | Command line | Date and time | Action(s)  | 
Altered

---
35 | update   | 2017-08-07 09:07 | E, I, O, U 
|  470 EE



Acording to yum history info, this are the ipa packages that where 
updated:

Obsoleted ipa-admintools-4.4.0-14.el7_3.7.noarch @rhel7
Updated ipa-client-4.4.0-14.el7_3.7.x86_64 @rhel7
Obsoleting ipa-client-4.5.0-21.el7.x86_64 @rhel7
Updated ipa-client-common-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch @rhel7
Updated ipa-common-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch@rhel7
Updated ipa-python-compat-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch @rhel7
Updated ipa-server-4.4.0-14.el7_3.7.x86_64 @rhel7
Update 4.5.0-21.el7.x86_64@rhel7
Updated ipa-server-common-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch @rhel7
Updated ipa-server-dns-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch@rhel7
Updated libipa_hbac-1.14.0-43.el7_3.18.x86_64 @rhel7
Update 1.15.2-50.el7.x86_64  @rhel7
Updated python-libipa_hbac-1.14.0-43.el7_3.18.x86_64 @rhel7
Update 1.15.2-50.el7.x86_64   @rhel7
Updated python2-ipaclient-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch @rhel7
Updated python2-ipalib-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch@rhel7
Updated python2-ipaserver-4.4.0-14.el7_3.7.noarch @rhel7
Update 4.5.0-21.el7.noarch @rhel7
Updated sssd-ipa-1.14.0-43.el7_3.18.x86_64 @rhel7
Update 1.15.2-50.el7.x86_64 @rhel7


Again, thanks for the help!
Kind regards


On Tue, Aug 8, 2017 at 5:51 AM, Pavel Vomacka > wrote:




On 08/07/2017 07:01 PM, Gustavo Berman via FreeIPA-users wrote:

Hello Pavel

On Mon, Aug 7, 2017 at 12:40 PM, Pavel Vomacka
> wrote:


Hello Gustavo,

From what I can see, the issue would be PROTOCOL ERROR in
whoami command. Could you please check whether all services
running? Please run
# ipactl status

and post the output.


# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful


And please could you send me the /etc/named.conf? Especially
everything after
 dyndb "ipa"
line is interesting for us.


This is from /etc/named.conf

options {
// turns on IPv6 for port 53, IPv4 is on by default for
all ifaces
listen-on-v6 {any;};

// Put files that named is allowed to write in the data/
directory:
directory "/var/named"; // the default
dump-file "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";

forward only;
forwarders {
10.73.2.100;
10.73.2.102;
10.73.2.101;
};

// Any host is permitted to issue recursive queries
allow-recursion { any; };

tkey-gssapi-keytab "/etc/named.keytab";
pid-file "/run/named/named.pid";
dnssec-enable yes;
dnssec-validation no;
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};

/* If you want to enable debugging, eg. using the 'rndc trace'
command,
 * By default, SELinux policy does not allow named to modify the
/var/named directory,
 * so put the default debug log file in data/ :
 */
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
print-time yes;
};
};

zone "." IN {
type hint;
file

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

2017-08-09 Thread Jakub Hrozek via FreeIPA-users 

> On 9 Aug 2017, at 16:26, Alexandre Pitre  wrote:
> 
> If your hosts are in the IPA subdomain, then I would have expected 
> centos.ipa.ad.com 
> 
> The centos client has a hostname set to centos.domain.ad.com 
>  I'm using FQDN hostname based on the required 
> DNS domain, not the IPA kerberos realm. Hence why centos.domain.ad.com 
> .
> 
> To explain further more, It'll probably be easier to use ipa.ad.com 
>  for all for my clients and not deal with a different DNS 
> domain than the IPA realm. However, we have this business requirement to use 
> a a different domain than the IPA realm. My understanding is that supposed to 
> be supported by using the --domain switch of ipa-client-install: 
> http://www.unix.com/man-page/centos/1/ipa-client-install/ 
>  which basically 
> just add static entires in /etc/sssd/sssd.conf and /etc/krb5.conf
> 

Could you please paste once again the client’s sssd-users.conf?

I think the issue is that the hostname is used during the LDAP GSSAPI bind and 
it doesn’t match the client’s name on the IDM side (so, the client thinks it’s 
centos.domain.ad.com  as far as its hostname is 
concerned but the IDM master only knows about centos.ipa.ad.com 
, right? That’s how the client is enrolled in IDM?)

If what I speculated above is true, then just adding:
   ipa_hostname = centos.ipa.ad.com 
Into sssd.conf’s domain section might do the trick.

> Should I approach things differently ?
> 

I think it’s only a matter of configuration (and it took me three reads of the 
e-mails until I spotted how the domains are configured..)

> 
> What is the relation between domain.ad.com  and ad.com 
>  and ipa.ad.com ?
> 
> ad.com  is my Active Directory domain.
> domain.ad.com  is a sub domain that was delegated from 
> the AD DNS to the freeipa servers
> ipa.ad.com  is also a sub domain that was delegated from 
> the AD DNS to the freeipa servers and is the freeipa native kerberos realm.
> 
> 
> 
> On Wed, Aug 9, 2017 at 9:55 AM, Jakub Hrozek  > wrote:
> 
>> On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users 
>> > > wrote:
>> 
>> The client is in the IPA domain. Although it's sub-domain of ad.com 
>> , I did delegate it and configure the IPA servers as name 
>> servers.  It uses a different domain suffix than ipa realm which was 
>> specified by ipa-client-install:
>> 
> 
> OK, but in the logs, I see:
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com ]]] 
> [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: 
> host/centos.domain.ad.com 
> 
> —> centos.domain.ad.com 
> 
> If your hosts are in the IPA subdomain, then I would have expected 
> centos.ipa.ad.com 
> 
> What is the relation between domain.ad.com  and ad.com 
>  and ipa.ad.com ?
> 
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com ]]] 
> [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com ]]] 
> [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic 
> failure: GSSAPI Error: Unspecified GSS failure.  Minor c
> ode may provide more information (Server krbtgt/ad@ipa.ad.com 
>  not found in Kerberos database)]
> 
>> ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates --mkhomedir 
>> --domain=domain.ad.com  --realm=IPA.AD.COM 
>>  --server=ipaserver01.ipa.ad.com 
>>  --server=ipaserver02.ipa.ad.com 
>>  --no-ntp --debug
>> 
>> 
>> 
>> On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek > > wrote:
>> 
>>> On 7 Aug 2017, at 18:11, Alexandre Pitre >> > wrote:
>>> 
>>> Clearing the sssd cache make the AD login works for a short while, it's 
>>> probably not necessary nor "production" ready. Looking at 
>>> /var/log/sssd/sssd_domain.ad.com . 
>> 
>> Sure, but that’s not what I meant. What I meant is that just “systemctl 
>> restart sssd” clears the online/offline state.
>> 
>> Removing the sssd cache is not needed and can actually be quite dangerous. I 
>> wish people just stopped doing that, because

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

2017-08-09 Thread Alexandre Pitre via FreeIPA-users 
If your hosts are in the IPA subdomain, then I would have expected
centos.ipa.ad.com

The centos client has a hostname set to centos.domain.ad.com I'm using FQDN
hostname based on the required DNS domain, not the IPA kerberos realm.
Hence why centos.domain.ad.com.

To explain further more, It'll probably be easier to use ipa.ad.com for all
for my clients and not deal with a different DNS domain than the IPA realm.
However, we have this business requirement to use a a different domain than
the IPA realm. My understanding is that supposed to be supported by using
the --domain switch of ipa-client-install:
http://www.unix.com/man-page/centos/1/ipa-client-install/ which basically
just add static entires in /etc/sssd/sssd.conf and /etc/krb5.conf

Should I approach things differently ?


What is the relation between domain.ad.com and ad.com and ipa.ad.com?

ad.com is my Active Directory domain.
domain.ad.com is a sub domain that was delegated from the AD DNS to the
freeipa servers
ipa.ad.com is also a sub domain that was delegated from the AD DNS to the
freeipa servers and is the freeipa native kerberos realm.



On Wed, Aug 9, 2017 at 9:55 AM, Jakub Hrozek  wrote:

>
> On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> The client is in the IPA domain. Although it's sub-domain of ad.com, I
> did delegate it and configure the IPA servers as name servers.  It uses a
> different domain suffix than ipa realm which was specified by
> ipa-client-install:
>
>
> OK, but in the logs, I see:
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
> centos.domain.ad.com
>
> —> centos.domain.ad.com
>
> If your hosts are in the IPA subdomain, then I would have expected
> centos.ipa.ad.com
>
> What is the relation between domain.ad.com and ad.com and ipa.ad.com?
>
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0020): ldap_sasl_bind failed (-2)[Local error]
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure.  Minor c
> ode may provide more information (Server krbtgt/ad@ipa.ad.com not
> found in Kerberos database)]
>
> ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates
> --mkhomedir --domain=domain.ad.com --realm=IPA.AD.COM 
>  --server=ipaserver01.ipa.ad.com --server=ipaserver02.ipa.ad.com --no-ntp
> --debug
>
>
>
> On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek  wrote:
>
>>
>> On 7 Aug 2017, at 18:11, Alexandre Pitre 
>> wrote:
>>
>> Clearing the sssd cache make the AD login works for a short while, it's
>> probably not necessary nor "production" ready. Looking at /var/log/sssd/
>> sssd_domain.ad.com.
>>
>>
>> Sure, but that’s not what I meant. What I meant is that just “systemctl
>> restart sssd” clears the online/offline state.
>>
>> Removing the sssd cache is not needed and can actually be quite
>> dangerous. I wish people just stopped doing that, because in case
>> credentials are cached, removing the cache also removes the credentials,
>> leaving users with no way to authenticate.
>>
>> I do see offline messages:
>>
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
>> [Input/output error])
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
>> (0x2000): Going offline!
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
>> (0x2000): Enable check_if_online_ptask.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_enable]
>> (0x0400): Task [Check if online (periodic)]: enabling task
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
>> (0x0400): Task [Check if online (periodic)]: scheduling task 65 seconds
>> from now [1502119252]
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_run_offline_cb]
>> (0x0080): Going offline. Running callbacks.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_op_connect_done] (0x4000): notify offline to op #1
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to
>> LDAP [11]: Resource temporarily unavailable
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is
>> available, cannot get the subdomain list while offline
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_done]
>> (0x0040): Task [Subdomains Refresh]: failed with [1432158212]: SSSD is
>> offline
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
>> (0x0400): Task [Subdomains Refresh]: scheduling task 14400 seconds from now
>> [1502133587]
>> (Mon Aug  7 15:19:47 2017)

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Michael Gusek via FreeIPA-users 
Hello Tomasz,

thx for your hint. I've disabled all selftests in
/etc/pki/pki-tomcat/ca/CS.cfg and /etc/pki/pki-tomcat/kra/CS.cfg. There
where only one test. But i did'nt get any success. CA won't start. :(

Michael


Am 09.08.2017 um 15:24 schrieb Tomasz Torcz via FreeIPA-users:
> On Wed, Aug 09, 2017 at 01:32:43PM +0200, Michael Gusek via FreeIPA-users 
> wrote:
>> Hello Rob,
>>
>> i can understand why CA won't start with expired certs. Actually my
>> system date is a day before expiring (expiring date is 30 Jul 2017,
>> system date now 29 Jul 2017), but CA won't start. How to "ensure that
>> the CA comes up" ?
>   There are couple of certificate selftests run at startup, you can see
> the logs at
>
>   /var/log/pki/pki-tomcat/ca/selftests.log
>
>   If any of them fails, CA won't start. You will have to fix the situation 
> causing
> test to fail or disabled them alltogether (/etc/pki/pki-tomcat/ca/CS.cfg, look
> for selftest.container.*).
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ID view is not overriding user attributes

2017-08-09 Thread Jakub Hrozek via FreeIPA-users 

> On 9 Aug 2017, at 16:02, Supratik Goswami via FreeIPA-users 
>  wrote:
> 
> (Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp. 
> example .com 
> ]]] [acctinfo_callback] (0x0100): Request 
> processed. Returned 1,11,Offline
> 

This is important. Check in the logs why is sssd going offline. Look for ‘Going 
offline’ or ‘Marking port as not working’ or similar in the logs.___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ID view is not overriding user attributes

2017-08-09 Thread Supratik Goswami via FreeIPA-users 
Hi Jakub,

Thanks for looking into the issue, please find the details you have
requested.

1. ipa idoverrideuser-show "Default Trust View"
supratik.gosw...@ad.corp.example.com
  Anchor to override: supratik.gosw...@ad.corp.example.com
  Login shell: /bin/bash
  SSH public key: ssh-rsa

B3NzaC1yc2EDAQABAAABAQDzeYIANc6N/96ko+cxz3aZVvGnttWjA8+939hb2eWFfM+2SKhVJylU0GPrHpKDRuE2letQxdPE+jI4gabiM3p0x7BeuxDPrPtQ5CoOK9JmYrEuom89p6UPs9tZCtx2glWSybeSENtPLj9pxfZN7dJvYtrGwSrgYHNtJ9dyEVN34ho1ZEsw3ARJW0sV4ccBJNuKEeswotCvWJag9L4yBQf7mUEJpKAcKfrPocP4BC1PiTQ5mgtykcd88dakd0zATpVS99t+JABH95MhXt4kKYgLg1wiqg8NKxz5Nkn9k1BGxM9NNZ3lA0zrijJVcwdsRDvl6rFyXUCHXaDJZR5Pehdv
  supratik@Supratiks-MacBook-Pro.local

2. ipa idoverrideuser-show "Default Trust View"
supratik.gosw...@ad.corp.example.com --all --raw
  dn:
ipaanchoruuid=:SID:S-1-5-21-3704658179-702631923-1581593159-1129,cn=Default
Trust View,cn=views,cn=accounts,dc=ipa,dc=corp,dc=example,dc=com
  ipaanchoruuid: :SID:S-1-5-21-3704658179-702631923-1581593159-1129
  loginshell: /bin/bash
  ipasshpubkey:
c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFCQVFEemVZSUFOYzZOLzk2a28rY3h6M2FaVnZHbnR0V2pBOCs5MzloYjJlV0ZmTSsyU0toVkp5bFUwR1BySHBLRFJ1RTJsZXRReGRQRStqSTRnYWJpTTNwMHg3QmV1eERQclB0UTVDb09LOUptWXJFdW9tODlwNlVQczl0WkN0eDJnbFdTeWJlU0VOdFBMajlweGZaTjdkSnZZdHJHd1NyZ1lITnRKOWR5RVZOMzRobzFaRXN3M0FSSlcwc1Y0Y2NCSk51S0Vlc3dvdEN2V0phZzlMNHlCUWY3bVVFSnBLQWNLZnJQb2NQNEJDMVBpVFE1bWd0eWtjZDg4ZGFrZDB6QVRwVlM5OXQrSkFCSDk1TWhYdDRrS1lnTGcxd2lxZzhOS3h6NU5rbjlrMUJHeE05Tk5aM2xBMHpyaWpKVmN3ZHNSRHZsNnJGeVhVQ0hYYURKWlI1UGVoZHYgc3VwcmF0aWtAU3VwcmF0aWtzLU1hY0Jvb2stUHJvLmxvY2Fs
  ipaoriginaluid: supratik.gosw...@ad.corp.example.com
  objectClass: ipaOverrideAnchor
  objectClass: top
  objectClass: ipaUserOverride
  objectClass: ipasshuser
  objectClass: ipaSshGroupOfPubKeys
  sshpubkeyfp: 1A:6E:50:EC:5C:DD:9F:80:39:B2:81:C3:49:61:73:67
supratik@Supratiks-MacBook-Pro.local (ssh-rsa)


3. date; sss_ssh_authorizedkeys supratik.gos...@ad.corp.example.com; date
Wed Aug  9 13:58:13 UTC 2017
Error looking up public keys
Wed Aug  9 13:58:13 UTC 2017



(Wed Aug  9 13:58:12 2017) [sssd[be[ipa.corp.example.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x23ff770
(Wed Aug  9 13:58:12 2017) [sssd[be[ipa.corp.example.com]]] [sbus_dispatch]
(0x4000): Dispatching.
(Wed Aug  9 13:58:12 2017) [sssd[be[ipa.corp.example.com]]]
[sbus_message_handler] (0x2000): Received SBUS method
org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service
(Wed Aug  9 13:58:12 2017) [sssd[be[ipa.corp.example.com]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x2420ca0
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]] [sbus_dispatch]
(0x4000): Dispatching.
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]]
[sbus_message_handler] (0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]]
[be_get_account_info] (0x0200): Got request for
[0x1][1][name=supratik.goswai]
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]]
[be_req_set_domain] (0x0400): Changing request domain from
[ipa.corp.example.com]
to [ad.corp.example.com]
(Wed Aug  9 13:58:13 2017) [sssd[be[ipa.corp.example.com]]]
[acctinfo_callback] (0x0100): Request processed. Returned 1,11,Offline
(Wed Aug  9 13:58:22 2017) [sssd[be[ipa.corp.example.com]]] [sbus_dispatch]
(0x4000): dbus conn: 0x23ff770
(Wed Aug  9 13:58:22 2017) [sssd[be[ipa.corp.example.com]]] [sbus_dispatch]
(0x4000): Dispatching.
(Wed Aug  9 13:58:22 2017) [sssd[be[ipa.corp.example.com]]]
[sbus_message_handler] (0x2000): Received SBUS method
org.freedesktop.sssd.service.ping on path /org/freedesktop/sssd/service
(Wed Aug  9 13:58:22 2017) [sssd[be[ipa.corp.example.com]]]
[sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit




On Wed, Aug 9, 2017 at 6:43 PM, Jakub Hrozek via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

>
> On 9 Aug 2017, at 14:37, Supratik Goswami via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> Can someone please help me to figure out the issue?
>
> Please let me know if any other information is required
>
>
> Describing how you set up the idview and providing SSSD logs is a good
> start.
>
> -  idoverrideuser-show “Default Trust View” supratik.gos...@ad.corp.
> example.com
> - the same with —all —raw
> - enable sssd logs on the client
> - run: date; sss_ssh_authorizedkeys supratik.gos...@ad.corp.example.com;
> date
> - attach the sssd logs
>
> On Wed, Aug 9, 2017 at 9:54 AM, Supratik Goswami  > wrote:
>
>> (Wed Aug  9 04:20:14 2017) [sssd[be[ipa.corp.example.com]]]
>> [sdap_get_generic_ext_step] (0x0400): calling

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

2017-08-09 Thread Jakub Hrozek via FreeIPA-users 

> On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users 
>  wrote:
> 
> The client is in the IPA domain. Although it's sub-domain of ad.com 
> , I did delegate it and configure the IPA servers as name 
> servers.  It uses a different domain suffix than ipa realm which was 
> specified by ipa-client-install:
> 

OK, but in the logs, I see:
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com ]]] 
[sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: 
host/centos.domain.ad.com 

—> centos.domain.ad.com 

If your hosts are in the IPA subdomain, then I would have expected 
centos.ipa.ad.com

What is the relation between domain.ad.com  and ad.com 
 and ipa.ad.com ?

(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com ]]] 
[sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com ]]] 
[sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic 
failure: GSSAPI Error: Unspecified GSS failure.  Minor c
ode may provide more information (Server krbtgt/ad@ipa.ad.com 
 not found in Kerberos database)]

> ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates --mkhomedir 
> --domain=domain.ad.com  --realm=IPA.AD.COM 
>  --server=ipaserver01.ipa.ad.com 
>  --server=ipaserver02.ipa.ad.com 
>  --no-ntp --debug
> 
> 
> 
> On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek  > wrote:
> 
>> On 7 Aug 2017, at 18:11, Alexandre Pitre > > wrote:
>> 
>> Clearing the sssd cache make the AD login works for a short while, it's 
>> probably not necessary nor "production" ready. Looking at 
>> /var/log/sssd/sssd_domain.ad.com . 
> 
> Sure, but that’s not what I meant. What I meant is that just “systemctl 
> restart sssd” clears the online/offline state.
> 
> Removing the sssd cache is not needed and can actually be quite dangerous. I 
> wish people just stopped doing that, because in case credentials are cached, 
> removing the cache also removes the credentials, leaving users with no way to 
> authenticate.
> 
>> I do see offline messages:
>> 
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 
>> [Input/output error])
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_mark_offline] (0x2000): Going offline!
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_mark_offline] (0x2000): Enable check_if_online_ptask.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling 
>> task 65 seconds from now [1502119252]
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_run_offline_cb] (0x0080): Going offline. Running callbacks.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [sdap_id_op_connect_done] (0x4000): notify offline to op #1
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to LDAP 
>> [11]: Resource temporarily unavailable
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is available, 
>> cannot get the subdomain list while offline
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_ptask_done] (0x0040): Task [Subdomains Refresh]: failed with 
>> [1432158212]: SSSD is offline
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_ptask_schedule] (0x0400): Task [Subdomains Refresh]: scheduling task 
>> 14400 seconds from now [1502133587]
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [sdap_id_release_conn_data] (0x4000): releasing unused connection
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com ]]] 
>> [be_ptask_online_cb] (0x0400): Back end is online
>> 
>> I uploaded  the full log file /var/log/sssd/sssd_domain.ad.com 
>>  
>> https://1drv.ms/f/s!AlZwwyQE2ZZ5p2ZmHLzmeKN7mBJ3 
>> 
>> 
>> Both my IPA servers looks healthy.AD

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Tomasz Torcz via FreeIPA-users 
On Wed, Aug 09, 2017 at 01:32:43PM +0200, Michael Gusek via FreeIPA-users wrote:
> Hello Rob,
> 
> i can understand why CA won't start with expired certs. Actually my
> system date is a day before expiring (expiring date is 30 Jul 2017,
> system date now 29 Jul 2017), but CA won't start. How to "ensure that
> the CA comes up" ?

  There are couple of certificate selftests run at startup, you can see
the logs at

  /var/log/pki/pki-tomcat/ca/selftests.log

  If any of them fails, CA won't start. You will have to fix the situation 
causing
test to fail or disabled them alltogether (/etc/pki/pki-tomcat/ca/CS.cfg, look
for selftest.container.*).

-- 
Tomasz Torcz   ,,(...) today's high-end is tomorrow's embedded processor.''
xmpp: zdzich...@chrome.pl  -- Mitchell Blank on LKML
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Unable to login with AD users

2017-08-09 Thread Jakub Hrozek via FreeIPA-users 

> On 8 Aug 2017, at 16:58, Eddleman, David via FreeIPA-users 
>  wrote:
> 
> Hello,
>  
> I have created a FreeIPA solution using Red Hat’s IDM product.
> FreeIPA version: 4.5.0
> OS version: RHEL 7.4
>  
> I have successfully installed the server portion and can authenticate to it 
> using local IDM users, such as the ‘admin’ user. I have created a one-way 
> trust between the IPA realm and an AD realm successfully, as `ipa trust-show` 
> demonstrates, returning the SID of the domain. I have also created the local 
> POSIX and external groups and mapped them. `ipa group-show ` 
> returns the external member SID just fine.
>  
> However, I cannot authenticate in the server over SSH using one of those AD 
> users. I’ve checked the HBAC rules and they are fine. One thing I noticed 
> when monitoring the securelog when testing is that the IDM users make a call 
> to pam_sss, as expected, but the AD users do not.

This probably means the user can’t be resolved at all, so the authentication 
process doesn’t even make it to the PAM phase. Does ‘getent passwd 
user@domainfqdn’ work?

Are you testing on the IDM server itself or on one of the clients? I would 
suggest to make the IDM server work first.

Either way, you’ll want to enable the SSSD debug logs and take a look there.

> I have tried multiple ways of passing the user and all are rejected -- 
> user@netbios, user@domainfqdn, netbios\user, and domainfqdn\user.

Either netbios\user or user@domainfqdn work, the others do not.

>  
> The user in question is in a single group in AD, and it has been tested with 
> the group being both Domain Local and Universal with the same results. There 
> is only one member of the group, the user that I am attempting login with.

Don’t use domain-local groups. Domain-local groups can only be assigned to a 
cross-forest group membership by accident, IPA needs to be fixed to disallow 
that.

Domain-local groups are just that, local to the domain they are defined in and 
during login, the membership to a domain local group from a non-local domain is 
stripped from the PAC and would remove the group membership of the user in that 
group during login.

>  
> Have I missed something?
>  
> David Eddleman
>  
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ID view is not overriding user attributes

2017-08-09 Thread Jakub Hrozek via FreeIPA-users 

> On 9 Aug 2017, at 14:37, Supratik Goswami via FreeIPA-users 
>  wrote:
> 
> Can someone please help me to figure out the issue? 
> 
> Please let me know if any other information is required
> 

Describing how you set up the idview and providing SSSD logs is a good start.

-  idoverrideuser-show “Default Trust View” supratik.gos...@ad.corp.example.com 

- the same with —all —raw
- enable sssd logs on the client
- run: date; sss_ssh_authorizedkeys supratik.gos...@ad.corp.example.com 
; date
- attach the sssd logs

> On Wed, Aug 9, 2017 at 9:54 AM, Supratik Goswami  > wrote:
> (Wed Aug  9 04:20:14 2017) [sssd[be[ipa.corp.example.com 
> ]]] [sdap_get_generic_ext_step] (0x0400): 
> calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=supratik.goswami))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=ipa,dc=corp,dc=example,dc=com]
> 
> What I could see here is that it is searching as 'supratik.goswami' and not 
> 'supratik.gos...@ad.corp.example.com 
> ' which is the ID View user in 
> the IPA.
> 
> How do I fix this?
> 
> On Wed, Aug 9, 2017 at 8:53 AM, Supratik Goswami  > wrote:
> Hello everyone,
> 
> I have a trust setup between AD and IPA, I have created a user in the 
> "Default Trust View" and
> updated the ssh public keys for that user.
> 
> When I am trying to login to any Linux system using the ad user it is not 
> able to find the keys.
> 
> Here is the sshd debug log.
> 
> Aug  9 03:04:01 host01 sshd[20102]: debug3: Running AuthorizedKeysCommand: 
> "/usr/bin/sss_ssh_authorizedkeys supratik.gosw...@ad.corp.example.com 
> " as "nobody"
> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
> Aug  9 03:04:01 host01 sshd[20102]: debug1: temporarily_use_uid: 99/99 (e=0/0)
> Aug  9 03:04:01 host01 sshd[20106]: debug3: sshd_selinux_setup_variables: 
> setting execution context
> Aug  9 03:04:01 host01 sshd[20102]: debug2: key not found
> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
> 
> My sshd_config file has the following entries
> 
> AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
> AuthorizedKeysCommandUser nobody
> 
> What could be the issue?
> 
> 
> Thanks
> 
> -- 
> Warm Regards
> 
> Supratik
> 
> 
> 
> -- 
> Warm Regards
> 
> Supratik
> 
> 
> 
> -- 
> Warm Regards
> 
> Supratik
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org 
> 
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ID view is not overriding user attributes

2017-08-09 Thread Supratik Goswami via FreeIPA-users 
Can someone please help me to figure out the issue?

Please let me know if any other information is required

On Wed, Aug 9, 2017 at 9:54 AM, Supratik Goswami 
wrote:

> (Wed Aug  9 04:20:14 2017) [sssd[be[ipa.corp.example.com]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(objectClass=ipaUserOverride)(uid=supratik.goswami))][cn=Default Trust
> View,cn=views,cn=accounts,dc=ipa,dc=corp,dc=example,dc=com]
>
> What I could see here is that it is searching as 'supratik.goswami' and
> not 'supratik.gos...@ad.corp.example.com' which is the ID View user in
> the IPA.
>
> How do I fix this?
>
> On Wed, Aug 9, 2017 at 8:53 AM, Supratik Goswami  > wrote:
>
>> Hello everyone,
>>
>> I have a trust setup between AD and IPA, I have created a user in the
>> "Default Trust View" and
>> updated the ssh public keys for that user.
>>
>> When I am trying to login to any Linux system using the ad user it is not
>> able to find the keys.
>>
>> Here is the sshd debug log.
>>
>> Aug  9 03:04:01 host01 sshd[20102]: debug3: Running
>> AuthorizedKeysCommand: "/usr/bin/sss_ssh_authorizedkeys
>> supratik.gosw...@ad.corp.example.com" as "nobody"
>> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
>> Aug  9 03:04:01 host01 sshd[20102]: debug1: temporarily_use_uid: 99/99
>> (e=0/0)
>> Aug  9 03:04:01 host01 sshd[20106]: debug3: sshd_selinux_setup_variables:
>> setting execution context
>> Aug  9 03:04:01 host01 sshd[20102]: debug2: key not found
>> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
>>
>> My sshd_config file has the following entries
>>
>> AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
>> AuthorizedKeysCommandUser nobody
>>
>> What could be the issue?
>>
>>
>> Thanks
>>
>> --
>> Warm Regards
>>
>> Supratik
>>
>
>
>
> --
> Warm Regards
>
> Supratik
>



-- 
Warm Regards

Supratik
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Michael Gusek via FreeIPA-users 
One more info. After starting tomcat-pki i have a exception in
catalina.2017-07-29.log:

Jul 29, 2017 10:06:58 AM org.apache.catalina.core.ContainerBase
addChildInternal
SCHWERWIEGEND: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/pki]]
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:153)
  at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
  at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
  at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
  at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)
Caused by: org.apache.catalina.LifecycleException: Error in resourceStart()
  at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5387)
  at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
  ... 14 more

Jul 29, 2017 10:06:58 AM org.apache.catalina.startup.HostConfig
deployDescriptor
SCHWERWIEGEND: Error deploying configuration descriptor
/etc/pki/pki-tomcat/Catalina/localhost/pki.xml
java.lang.IllegalStateException: ContainerBase.addChild: start:
org.apache.catalina.LifecycleException: Failed to start component
[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/pki]]
  at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:903)
  at
org.apache.catalina.core.ContainerBase.access$000(ContainerBase.java:133)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:156)
  at
org.apache.catalina.core.ContainerBase$PrivilegedAddChild.run(ContainerBase.java:145)
  at java.security.AccessController.doPrivileged(Native Method)
  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:873)
  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
  at
org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:679)
  at
org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1966)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
  at java.util.concurrent.FutureTask.run(FutureTask.java:266)
  at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
  at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
  at java.lang.Thread.run(Thread.java:748)

I think thats we reason why CA not available, but there is no info whats
the underlying problem is.

Michael


Am 09.08.2017 um 13:32 schrieb Michael Gusek via FreeIPA-users:
>
> Hello Rob,
>
> i can understand why CA won't start with expired certs. Actually my
> system date is a day before expiring (expiring date is 30 Jul 2017,
> system date now 29 Jul 2017), but CA won't start. How to "ensure that
> the CA comes up" ?
>
> Michael
>
>
> Am 08.08.2017 um 17:40 schrieb Rob Crittenden:
>> Michael Gusek via FreeIPA-users wrote:
>>> Hi Fraser,
>>>
>>> at the moment, i can't provide this logfile, i've moved that back to
>>> have only new log lines. But a new new logfile is not created ??? In my
>>> old logfile i have some lines after switch to basic auth, but before
>>> setting time to past:
>>>
>> The CA won't start with expired certs.
>>
>> I'd set the time back to the past and ensure that the CA comes up. The
>> debug log in that case should tell you what is going on. Be sure that
>> ntpd is stopped.
>>
>> Restarting certmonger should be sufficient to have it try renewal as it
>> will see on startup that the certs need to be refreshed.
>>
>> rob
>
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com

Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer


___
FreeIPA-users

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-09 Thread Michael Gusek via FreeIPA-users 
Hello Rob,

i can understand why CA won't start with expired certs. Actually my
system date is a day before expiring (expiring date is 30 Jul 2017,
system date now 29 Jul 2017), but CA won't start. How to "ensure that
the CA comes up" ?

Michael


Am 08.08.2017 um 17:40 schrieb Rob Crittenden:
> Michael Gusek via FreeIPA-users wrote:
>> Hi Fraser,
>>
>> at the moment, i can't provide this logfile, i've moved that back to
>> have only new log lines. But a new new logfile is not created ??? In my
>> old logfile i have some lines after switch to basic auth, but before
>> setting time to past:
>>
> The CA won't start with expired certs.
>
> I'd set the time back to the past and ensure that the CA comes up. The
> debug log in that case should tell you what is going on. Be sure that
> ntpd is stopped.
>
> Restarting certmonger should be sufficient to have it try renewal as it
> will see on startup that the certs need to be refreshed.
>
> rob


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org