Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem

[Petr Spacek]

On 22.6.2016 02:56, Sean Hogan wrote:
> More info
> 
> 
> Krb5 log is showing:
> Jun 21 20:42:47 Firstmaster.domain.local krb5kdc[2141](info): AS_REQ (4
> etypes {18 17 16 23}) 10.x.x.x: LOOKING_UP_CLIENT: admin@domain.LOCAL for
> krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL, Server error


Hello,

this is really fishy. I would bet that there is a problem with LDAP server and
DNS errors are just consequence of it.

I suspect that you will not be able to finish steps mentioned in
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a3.FailedtoinitcredentialsorFailedtogetinitialcredentialsDecryptintegritycheckfailedorClientscredentialshavebeenrevoked

If it is the case I would turn your attention to krb5kdc.log and LDAP server
logs in /var/log/dirsrv/*

There must be something wrong with the LDAP server.

Petr^2 Spacek


> 
> [bob@Firstmaster etc]# kinit -v admin
> kinit: Credentials cache file '/tmp/krb5cc_0' not found while validating
> credentials
> 
> 
> 
> 
> 
> 
> Sean Hogan
> 
> 
> 
> 
> 
> 
> From: Sean Hogan/Durham/IBM
> To:   freeipa-users 
> Date: 06/21/2016 12:02 PM
> Subject:  Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem
> 
> 
>   Has anyone seen these before?
> 
> 
> 
> First Master IPA DNS logs show:   Looks like the host names are getting the
> domain twice domain.local.domain.local
> 
> 
> client 10.x.x.x#58094: query failed (SERVFAIL) for
> server1.domain.local.domain.local/IN/ at query.c:6569
> timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
> potential deadlock?
> client 10.x.x.x#44147: query failed (SERVFAIL) for
> x.x.x.10.in-addr.arpa/IN/PTR at query.c:6569
> timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
> potential deadlock?
> client 10.x.x.x#56466: query failed (SERVFAIL) for
> x.x.x.10.in-addr.arpa/IN/PTR at query.c:6569
> timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
> potential deadlock?
> client 10.x.x.x53367: query failed (SERVFAIL) for
> server2.domain.local.domain.local/IN/A at query.c:6569
> timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
> potential deadlock?
> client 10.x.x.x#53367: query failed (SERVFAIL) for
> server2.domain.local.domain.local/IN/ at query.c:6569
> 
> 
> 
> So enrolls are failing at this point when tyring to enroll to a replica:
> 
> [bob@server1 log]# ipa-client-install –enable-dns-updates
> Discovery was successful!
> Hostname: server1.watson.local
> Realm: DOMAIN.LOCAL
> DNS Domain: domain.local
> IPA Server: ipareplica.domain.local
> BaseDN: dc=domain,dc=local
> 
> Continue to configure the system with these values? [no]: yes
> User authorized to enroll computers: bob
> Synchronizing time with KDC...
> Password for bob@DOMAIN.LOCAL:
> Successfully retrieved CA cert
> Subject: CN=Certificate Authority,O=DOMAIN.LOCAL
> Issuer:  CN=Certificate Authority,O=DOMAIN.LOCAL
> Valid From:  Tue Jan 06 19:37:09 2015 UTC
> Valid Until: Sat Jan 06 19:37:09 2035 UTC
> 
> Enrolled in IPA realm DOMAIN.LOCAL
> Attempting to get host TGT...
> Created /etc/ipa/default.conf
> New SSSD config will be created
> Configured sudoers in /etc/nsswitch.conf
> Configured /etc/sssd/sssd.conf
> Configured /etc/krb5.conf for IPA realm DOMAIN.LOCAL
> trying https://ipareplica.domain.local/ipa/xml
> Cannot connect to the server due to Kerberos error: Kerberos error:
> Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
> information', 851968)/('KDC returned error string: PROCESS_TGS',
> -1765328324)/. Trying with delegate=True
> trying https://ipareplica.domain.local/ipa/xml
> Second connect with delegate=True also failed: Kerberos error: Kerberos
> error: ('Unspecified GSS failure.  Minor code may provide more
> information', 851968)/('KDC returned error string: PROCESS_TGS',
> -1765328324)/
> Cannot connect to the IPA server XML-RPC interface: Kerberos error:
> Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
> information', 851968)/('KDC returned error string: PROCESS_TGS',
> -1765328324)/
> Installation failed. Rolling back changes.
> Unenrolling client from IPA server
> Unenrolling host failed: Error obtaining initial credentials: Generic error
> (see e-text).
> 
> Removing Kerberos service principals from /etc/krb5.keytab
> Disabling client Kerberos and LDAP configurations
> Redundant SSSD configuration file /etc/sssd/sssd.conf was moved
> to /etc/sssd/sssd.conf.deleted
> Restoring client configuration files
> nscd daemon is not installed, skip configuration
> nslcd daemon is not installed, skip configuration
> Client uninstall complete.
> 
> 
> Sean Hogan
> 
> 
> 
> 
> 
> 
> 
> 
> From: Sean Hogan/Durham/IBM
> To:   Sean Hogan/Durham/IBM@IBMUS
> Cc:   freeipa-users 
> Date: 06/20/2016 12:49 PM
> Subject:  Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem
> 
> 
> Also seeing this in the upgrade log on the 

Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem

[Sean Hogan]

More info


Krb5 log is showing:
Jun 21 20:42:47 Firstmaster.domain.local krb5kdc[2141](info): AS_REQ (4
etypes {18 17 16 23}) 10.x.x.x: LOOKING_UP_CLIENT: admin@domain.LOCAL for
krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL, Server error

[bob@Firstmaster etc]# kinit -v admin
kinit: Credentials cache file '/tmp/krb5cc_0' not found while validating
credentials






Sean Hogan






From:   Sean Hogan/Durham/IBM
To: freeipa-users 
Date:   06/21/2016 12:02 PM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem


  Has anyone seen these before?



First Master IPA DNS logs show:   Looks like the host names are getting the
domain twice domain.local.domain.local


client 10.x.x.x#58094: query failed (SERVFAIL) for
server1.domain.local.domain.local/IN/ at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x#44147: query failed (SERVFAIL) for
x.x.x.10.in-addr.arpa/IN/PTR at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x#56466: query failed (SERVFAIL) for
x.x.x.10.in-addr.arpa/IN/PTR at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x53367: query failed (SERVFAIL) for
server2.domain.local.domain.local/IN/A at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x#53367: query failed (SERVFAIL) for
server2.domain.local.domain.local/IN/ at query.c:6569



So enrolls are failing at this point when tyring to enroll to a replica:

[bob@server1 log]# ipa-client-install –enable-dns-updates
Discovery was successful!
Hostname: server1.watson.local
Realm: DOMAIN.LOCAL
DNS Domain: domain.local
IPA Server: ipareplica.domain.local
BaseDN: dc=domain,dc=local

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: bob
Synchronizing time with KDC...
Password for bob@DOMAIN.LOCAL:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=DOMAIN.LOCAL
Issuer:  CN=Certificate Authority,O=DOMAIN.LOCAL
Valid From:  Tue Jan 06 19:37:09 2015 UTC
Valid Until: Sat Jan 06 19:37:09 2035 UTC

Enrolled in IPA realm DOMAIN.LOCAL
Attempting to get host TGT...
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm DOMAIN.LOCAL
trying https://ipareplica.domain.local/ipa/xml
Cannot connect to the server due to Kerberos error: Kerberos error:
Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('KDC returned error string: PROCESS_TGS',
-1765328324)/. Trying with delegate=True
trying https://ipareplica.domain.local/ipa/xml
Second connect with delegate=True also failed: Kerberos error: Kerberos
error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('KDC returned error string: PROCESS_TGS',
-1765328324)/
Cannot connect to the IPA server XML-RPC interface: Kerberos error:
Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('KDC returned error string: PROCESS_TGS',
-1765328324)/
Installation failed. Rolling back changes.
Unenrolling client from IPA server
Unenrolling host failed: Error obtaining initial credentials: Generic error
(see e-text).

Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved
to /etc/sssd/sssd.conf.deleted
Restoring client configuration files
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.


Sean Hogan








From:   Sean Hogan/Durham/IBM
To: Sean Hogan/Durham/IBM@IBMUS
Cc: freeipa-users 
Date:   06/20/2016 12:49 PM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem


Also seeing this in the upgrade log on the first master but not on the 7
ipas.

ERROR Failed to restart named: Command '/sbin/service named restart '
returned non-zero exit status 7


which led me to

https://bugzilla.redhat.com/show_bug.cgi?id=895298





Sean Hogan







From:   Sean Hogan/Durham/IBM@IBMUS
To: freeipa-users 
Date:   06/20/2016 11:46 AM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem
Sent by:freeipa-users-boun...@redhat.com



Hi All..

I thought we fixed this issue by rebooting the KVM host but it is showing
again. Our First Master IPA is being rebooted 2 -5 times a day now just to
keep it alive.

What we are seeing:

God@FirstMaster log]# kinit admin
kinit: Cannot contact any KDC for realm 'Domain.LOCAL' while getting
initial credentials

DNS is not working as nslookup is failing to a 

Re: [Freeipa-users] Active Directory password sync fails with RC 34

[Rich Megginson]

Great!  Glad you got that working.

Next step is to use AD trust instead of sync . . .

On 06/21/2016 12:58 AM, Toby Gale wrote:

Thanks for the help Rich.

Looking at the log I noticed some extra characters in the DN that 
corresponds to "Search Base".  I got the Windows admin to share his 
RDP session to the DC and had a look at the registry in 
"HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync". I noticed the same 
characters in the "Search Base" key.  I think the extra characters 
were accidentally copy-pasted from the documentation I sent them.


Removing them and restarting the service has resolved the problem.


On Mon, Jun 20, 2016 at 3:49 PM, Rich Megginson > wrote:


On 06/18/2016 05:47 AM, Toby Gale wrote:


Hello,

After successfully adding a 'winsync' agreement and loading AD
data into FreeIPA I am trying to configure the password sync
software on the domain controllers.

I have installed the certificates and can successfully bind from
the domain controller using ldp.exe and the
'uid=passsync,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com' user.

I have edited the registry to increase logging, by setting
'HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync\Log Level' to '1' and I
am seeing the error:

06/17/16 08:47:32: Backoff time expired.  Attempting sync
06/17/16 08:47:32: Password list has 1 entries
06/17/16 08:47:32: Attempting to sync password for some.user
06/17/16 08:47:32: Searching for (ntuserdomainid=some.user)
06/17/16 08:47:32: Ldap error in QueryUsername
34: Invalid DN syntax



Take a look at the 389/dirsrv access log on your linux host at
/var/log/dirsrv/slapd-HOSTNAME/access - see if you can find the
error corresponding to this - it should be at the same approximate
date/time (make sure you check your time zones) and the RESULT
line should have err=34


06/17/16 08:47:32: Deferring password change for some.user
06/17/16 08:47:32: Backing off for 1024000ms

When I run the query from the CLI, it is successful:

$ ldapsearch -x -h ldaps://localhost -p 636 -D
'uid=passsync,cn=sysaccounts,cn=etc,dc=dc,my=domain,dc=com' -w
'password'  -b 'cn=users,cn=accounts,dc=my,dc=domain,dc=com'
'(ntuserdomainid=some.user)'

Can anyone help me resolve this?

Thanks.






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

[Nathaniel McCallum]

I have found and fixed what I believe to be the issue. I have submitted
a patch upstream for review: https://github.com/krb5/krb5/pull/471

Once merged, we will backport the fix into all existing Fedora
releases. So you should get an update via a simple: dnf update.

On Thu, 2016-06-16 at 10:28 +0200, Winfried de Heiden wrote:
> Hi all,
> 
> "So it looks a bit like a libverto 32bit issue"; any news or progress
> on 
> this? Bugzilla?
> 
> Winny
> 
> 
> Op 09-06-16 om 18:51 schreef Sumit Bose:
> > On Thu, Jun 09, 2016 at 08:42:59AM -0400, Nathaniel McCallum wrote:
> > > On Thu, 2016-06-09 at 10:46 +0200, Sumit Bose wrote:
> > > > On Thu, Jun 09, 2016 at 08:16:13AM +0200, Winfried de Heiden
> > > > wrote:
> > > > > Hi all,
> > > > > 
> > > > > I can install libvert-libev but removing libverto-tevent will
> > > > > remove 123
> > > > > dependencies also. (wget, tomcat and much more...)
> > > > > 
> > > > > Hence, I installed libverto-libev, but dit not remove
> > > > > libverto-
> > > > > tevent to give
> > > > > it a try. After ipactl restart still the same problem:
> > > > fyi, I think I can reproduce the issue on 32bit Fedora. I tried
> > > > libverto-libev as well but I removed libverto-tevent after
> > > > installing
> > > > libverto-libev with 'rpm -e --nodeps ' to make sure
> > > > libverto has
> > > > no
> > > > other chance.
> > > > 
> > > > So it looks a bit like a libverto 32bit issue. I used
> > > > libverto-0.2.6-4.fc22. Since I knew that is was working before
> > > > on
> > > > 32bits
> > > > I tried libverto-0.2.5 and libverto-0.2.4 as well with no lock.
> > > > 
> > > > Nathaniel, do you have any suggestions what to check with gdb?
> > > It may not be a libverto issue at all. Just to summarize, krb5kdc
> > > sends
> > > the otp request to ipa-otpd using RADIUS-over-UNIX-socket.
> > > 
> > > It appears that ipa-otpd receives the request and sends the
> > > appropriate
> > > response. However, krb5kdc never appears to receive the request
> > > and
> > > times out. Once it times out, it closes the socket and ipa-otpd
> > > exits.
> > > 
> > > The question is: why?
> > > 
> > > This could be a bug in krb5kdc, libkrad or libverto. Does the
> > > event
> > > actually fire from libverto? Does libkrad process it correctly?
> > > Does
> > > krb5kdc process it correctly?
> > > 
> > > There are lots of places to attach gdb. I would probably start
> > > here:
> > > https://github.com/krb5/krb5/blob/master/src/lib/krad/client.c#L1
> > > 93
> > It looks like the 3rd argument of recv(), the buffer length,
> > becomes
> > negative aka very big in on_io_read()
> > 
> >  i = recv(verto_get_fd(rr->io), rr->buffer.data + rr-
> > >buffer.length,
> >   pktlen - rr->buffer.length, 0);
> > 
> > because pktlen is 4 and rr->buffer.length is 16 on my 32bit system.
> > I
> > wonder if pktlen isn't sufficient here because it already is the
> > result
> > of 'len - buffer->length' which is calculated in
> > krad_packet_bytes_needed() ?
> > 
> > bye,
> > Sumit
> > 
> 

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

Re: [Freeipa-users] AD trust with POSIX attributes

[Jakub Hrozek]

On Tue, Jun 21, 2016 at 01:55:54PM +0200, Jan Karásek wrote:
> Hi all, 
> 
> I have a questions about IPA with AD forest trust. What I am trying to do is 
> setup environment, where all informations about users are stored in one place 
> - AD. I would like to read at least uid, home, shell and sshkey from AD. 
> 
> I have set up trust with this parameters: 
> 
> ipa trust-add EXAMPLE.TT --type=ad --range-type=ipa-ad-trust-posix 
> --admin=administrator 

Did you add the POSIX attributes to AD after creating the trust maybe?

> 
> [root@ipa1 ~]# ipa idrange-show EXAMPLE.TT_id_range 
> Range name: EXAMPLE.TT_id_range 
> First Posix ID of the range: 139200 
> Number of IDs in the range: 20 
> Domain SID of the trusted domain: S-1-5-21-4123312533-990676102-3576722756 
> Range type: Active Directory trust range with POSIX attributes 
> 
> 
> I have set attributes in AD for u...@example.tt 
> - uidNumber -1 
> - homeDirectory -/home/user 
> - loginShell - /bin/bash 
> 
> Trust itself works fine. I can do kinit with u...@example.tt , I can run id 
> and getent passwd u...@example.tt and I can use u...@example.tt for ssh. 
> 
> Problem is, that I am not getting uid from AD but from idrange: 
> 
> uid=1392001107(u...@example.tt) 
> 
> Also I have tried to switch off id mapping in sssd.conf with ldap_id_mapping 
> = true in sssd.conf but no luck. 

This has no effect, in IPA-AD trust scenario, the id mapping properties
are managed on the server.

> 
> I know, that it is probably better to use ID views for this, but in our case 
> we need to set centrally managed environment, where all users information are 
> externally inserted to AD from HR system - included POSIX attributes and we 
> need IPA to read them from AD. 

I think idviews are better for overriding POSIX attributes for a
specific set of hosts, but in your environment, it sounds like you want
to use the POSIX attributes across the board.

> 
> So my questions are: 
> 
> Is it possible to read user's POSIX attributes directly from AD - namely uid 
> ? 

Yes

> Which atributes can be stored in AD ? 

Homedir is a bit special, for backwards compatibility the
subdomains_homedir takes precedence. The others should be read from AD.

I don't have the environment set at the moment, though, so I'm operating
purely from memory.

> Am I doing something wrong ? 
> 
> my sssd.conf: 
> [domain/a.example.tt] 
> debug_level = 5 
> cache_credentials = True 
> krb5_store_password_if_offline = True 
> ipa_domain = a.example.tt 
> id_provider = ipa 
> auth_provider = ipa 
> access_provider = ipa 
> ipa_hostname = ipa1.a.example.tt 
> chpass_provider = ipa 
> ipa_server = ipa1.a.example.tt 
> ipa_server_mode = True 
> ldap_tls_cacert = /etc/ipa/ca.crt 
> #ldap_id_mapping = true 
> #subdomain_inherit = ldap_user_principal 
> #ldap_user_principal = nosuchattribute 
> 
> [sssd] 
> services = nss, sudo, pam, ssh 
> config_file_version = 2 
> 
> domains = a.example.tt 
> [nss] 
> debug_level = 5 
> homedir_substring = /home 
> enum_cache_timeout = 2 
> entry_negative_timeout = 2 
> 
> 
> [pam] 
> debug_level = 5 
> [sudo] 
> 
> [autofs] 
> 
> [ssh] 
> debug_level = 4 
> [pac] 
> 
> debug_level = 4 
> [ifp] 
> 
> Thanks, 
> Jan 

> -- 
> 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] IPA 3.0.47 to 3.0.50 Upgrade problem

[Sean Hogan]

  Has anyone seen these before?



First Master IPA DNS logs show:   Looks like the host names are getting the
domain twice domain.local.domain.local


client 10.x.x.x#58094: query failed (SERVFAIL) for
server1.domain.local.domain.local/IN/ at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x#44147: query failed (SERVFAIL) for
x.x.x.10.in-addr.arpa/IN/PTR at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x#56466: query failed (SERVFAIL) for
x.x.x.10.in-addr.arpa/IN/PTR at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x53367: query failed (SERVFAIL) for
server2.domain.local.domain.local/IN/A at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.x.x.x#53367: query failed (SERVFAIL) for
server2.domain.local.domain.local/IN/ at query.c:6569



So enrolls are failing at this point when tyring to enroll to a replica:

[bob@server1 log]# ipa-client-install –enable-dns-updates
Discovery was successful!
Hostname: server1.watson.local
Realm: DOMAIN.LOCAL
DNS Domain: domain.local
IPA Server: ipareplica.domain.local
BaseDN: dc=domain,dc=local

Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: bob
Synchronizing time with KDC...
Password for bob@DOMAIN.LOCAL:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=DOMAIN.LOCAL
Issuer:  CN=Certificate Authority,O=DOMAIN.LOCAL
Valid From:  Tue Jan 06 19:37:09 2015 UTC
Valid Until: Sat Jan 06 19:37:09 2035 UTC

Enrolled in IPA realm DOMAIN.LOCAL
Attempting to get host TGT...
Created /etc/ipa/default.conf
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm DOMAIN.LOCAL
trying https://ipareplica.domain.local/ipa/xml
Cannot connect to the server due to Kerberos error: Kerberos error:
Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('KDC returned error string: PROCESS_TGS',
-1765328324)/. Trying with delegate=True
trying https://ipareplica.domain.local/ipa/xml
Second connect with delegate=True also failed: Kerberos error: Kerberos
error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('KDC returned error string: PROCESS_TGS',
-1765328324)/
Cannot connect to the IPA server XML-RPC interface: Kerberos error:
Kerberos error: ('Unspecified GSS failure.  Minor code may provide more
information', 851968)/('KDC returned error string: PROCESS_TGS',
-1765328324)/
Installation failed. Rolling back changes.
Unenrolling client from IPA server
Unenrolling host failed: Error obtaining initial credentials: Generic error
(see e-text).

Removing Kerberos service principals from /etc/krb5.keytab
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file /etc/sssd/sssd.conf was moved
to /etc/sssd/sssd.conf.deleted
Restoring client configuration files
nscd daemon is not installed, skip configuration
nslcd daemon is not installed, skip configuration
Client uninstall complete.


Sean Hogan







From:   Sean Hogan/Durham/IBM
To: Sean Hogan/Durham/IBM@IBMUS
Cc: freeipa-users 
Date:   06/20/2016 12:49 PM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem


Also seeing this in the upgrade log on the first master but not on the 7
ipas.

ERROR Failed to restart named: Command '/sbin/service named restart '
returned non-zero exit status 7


which led me to

https://bugzilla.redhat.com/show_bug.cgi?id=895298





Sean Hogan







From:   Sean Hogan/Durham/IBM@IBMUS
To: freeipa-users 
Date:   06/20/2016 11:46 AM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem
Sent by:freeipa-users-boun...@redhat.com



Hi All..

I thought we fixed this issue by rebooting the KVM host but it is showing
again. Our First Master IPA is being rebooted 2 -5 times a day now just to
keep it alive.

What we are seeing:

God@FirstMaster log]# kinit admin
kinit: Cannot contact any KDC for realm 'Domain.LOCAL' while getting
initial credentials

DNS is not working as nslookup is failing to a replica think once we
lose DNS it all goes down hill which makes sense.

[god@FirstMaster log]# ipactl stop -> Just hangs forever.. no replies..
no error.. nothing

I try service named stop and nothing happens

I have the box hard shutdown from KVM console. Reboot it and it works for a
little while but eventually back to same behavior.

At this point I can service named stop and it responds... ipactl status and
it responds.. but when if I try service named restart I get

[god@FirstMaster log]# service named stop
Stopping named: ..

[Freeipa-users] Announcing FreeIPA 4.4.0 alpha1

[Petr Vobornik]

   == FreeIPA 4.4.0 Alpha 1 ===

The FreeIPA team would like to announce FreeIPA v4.4.0 alpha1 release!

A tarball can be downloaded from http://www.freeipa.org/page/Downloads

== Highlights in 4.4.0 Alpha 1 ==

Enhancements:
* Improved Topology Management

* Added Overview of IPA server roles:

* Added support certificates for AD users:

* Added support of UPN for trusted domains

* Added support for Kerberos Authentication Indicators

* Added DNS Location Mechanism

* Several performance improvements

* Refactored IPA command line tool

* Added support for Sub-CAs 

== Detailed Changelog since 4.3.1 ==

Abhijeet Kasurde (12):
  Added kpasswd_server directive in client krb5.conf
  Fixed login error message box in LoginScreen page
  Added fix for notifying user about Kerberos principal expiration
in WebUI
  Added description related to 'status' in ipactl man page
  Added warning to user for Internet Explorer
  Added fix for notifying user about locked user account in WebUI
  Updated ipa command man page
  Fix added to ipa-compat-manage command line help
  Removed custom implementation of CalledProcessError
  Replaced find_hostname with api.env.host
  Added exception handling for mal-formatted XML Parsing
  Added missing translation to automount.py method

Alexander Bokovoy (11):
  slapi-nis: update configuration to allow external members of IPA
groups
  extdom: do not fail to process error case when no request is specified
  otptoken: support Python 3 for the qr code
  trusts: Add support for an external trust to Active Directory domain
  adtrust: remove nttrustpartner parameter
  adtrust: remove nttrustpartner parameter
  adtrust: support GSSAPI authentication to LDAP as Active Directory
user
  adtrust: support UPNs for trusted domain users
  webui: show UPN suffixes in trust properties
  webui: support external flag to trust-add
  adtrust: optimize forest root LDAP filter

Christian Heimes (3):
  Require Dogtag 10.2.6-13 to fix KRA uninstall
  Modernize mod_nss's cipher suites
  Move user/group constants for PKI and DS into ipaplatform

David Kupka (28):
  installer: Propagate option values from components instead of
copying them.
  installer: Fix logic of reading option values from cache.
  ipa-dns-install: Do not check for zone overlap when DNS installed.
  ipa-replica-prepare: Add '--auto-reverse' and
'--allow-zone-overlap' options
  installer: Change reverse zones question to better reflect reality.
  Fix: Use unattended parameter instead of options.unattended
  CI: Add '2-connected' topology generator.
  CI: Add simple replication test in 2-connected topology.
  CI: Add test for 2-connected topology generator.
  CI: Fix pep8 errors in 2-connected topology generator
  CI: add empty topology test for 2-connected topology generator
  CI: Add double circle topology.
  CI: Add replication test utilizing double-circle topology.
  CI: Add test for double-circle topology generator.
  CI: Make double circle topology python3 compatible
  upgrade: Match whole pre/post command not just basename.
  dsinstance: add start_tracking_certificates method
  httpinstance: add start_tracking_certificates method
  Look up HTTPD_USER's UID and GID during installation.
  test: test_cli: Do not expect defaults in kwargs.
  man: Decribe ipa-client-install workaround for broken D-Bus
enviroment.
  installer: positional_arguments must be tuple or list of strings
  installer: index() raises ValueError
  Remove unused locking "context manager"
  schema: Add fingerprint and TTL
  schema: Add known_fingerprints option to schema command
  schema: Cache schema in api instance
  schema: return fingerprint as unicode text

Filip Skola (9):
  Refactor test_user_plugin, use UserTracker for tests
  Refactor test_replace
  Refactor test_attr
  Refactor test_sudocmd_plugin
  Refactor test_sudocmdgroup_plugin
  Refactor test_group_plugin, use GroupTracker for tests
  Refactor test_nesting, create HostGroupTracker
  Refactor test_hostgroup_plugin
  Refactor test_automember_plugin, create AutomemberTracker

Florence Blanc-Renaud (5):
  Add missing CA options to the manpage for ipa-replica-install
  Add the culprit line when a configuration file has an incorrect format
  add context to 

Re: [Freeipa-users] EXAMPLE.COM IPA CA Import /etc/httpd/alias

[Rob Crittenden]

Günther J. Niederwimmer wrote:

Hello Rob,

Am Mittwoch, 1. Juni 2016, 09:54:58 CEST schrieb Rob Crittenden:

Günther J. Niederwimmer wrote:

Hello,

Am Dienstag, 31. Mai 2016, 11:06:09 CEST schrieb Rob Crittenden:

Günther J. Niederwimmer wrote:

Hello
I found any Help for the IPA Certificate but I found no way to import
the
IPA CA ?
I like to create a webserver with a owncloud virtualhost and other..

But it is for me not possible to create the /etc/httpd/alias correct ?

I found this in IPA DOCS

certutil -A -d . -n 'EXAMPLE.COM IPA CA' -t CT,, -a < /etc/ipa/ca.crt

but with this command line I have a Error /etc/ipa/ca.crt have wrong
format ?

Have any a link with a working example


Does the file /etc/ipa/ca.crt exist? It is installed there on enrolled
clients so the documentation is written from that perspective.


Yes.


You can grab a copy from any enrolled system, including an IPA Master.
Otherwise the command looks ok assuming you were sitting in
/etc/httpd/alias when the command was executed (-d .).


Yes ;-).
but certutil mean it is a wrong format from the Certificate


$ mkdir /tmp/testdb && cd /tmp/testdb
$ certutil -N -d .
$ certutil -A -d . -n 'EXAMPLE.COM IPA CA' -t CT,, -a < /etc/ipa/ca.crt


On my system I have this message after install ca.crt

p11-kit: objects of this type cannot be created ?
is this correct ?


I'm not sure.


A other question, have I to change the Attribute (?), IPA-server create /
IMPORT this ca.crt with -t "CT,C,C"


It isn't super important. The order of those fields is SSL, S/MIME, 
code-signing. Chances are S/MIME will never be used and code-signing is 
used in some older releases but only once at install, so not having 
those set isn't a big deal.


If you want things to be consistent you can use certutil -M -d . -t 
CT,C,C -n 'EXAMPLE.COM IPA CA'


rob




$ certutil -L -d .

Certificate Nickname Trust
Attributes

SSL,S/MIME,JAR/XPI

EXAMPLE.COM IPA CA   CT,,

I guess look at what is in /etc/ipa/ca.crt and ensure it is valid. You
can use openssl for that:

$ openssl x509 -text -inform PEM -in /etc/ipa/ca.crt


Something is wrong on my system !!

for me it is not possible to have on a enrolled ipa-client a working
webserver (apache) with mod_NSS

The last Tests apache mean it is the wrong "passwd" for the DB and don't
start?

So now I start again with a new clean /etc/httpd/alias


Not knowing how you created the database or what your nss.conf looks
like it's hard to say what is going on. If you set a NSS database
password then you need to tell mod_nss about it.

Typically you'd set this in nss.conf:

NSSPassPhraseDialog "file:/etc/httpd/conf/password.conf"

and create /etc/httpd/conf/password.conf with contents like:

internal:SecretPassword123

Ensure that the file is owned by apache:apache and mode 0400.


This is the best INFO for this file ;-)

Thanks



--
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] Multiple issues (weblogin, DNS) with 4.3.1

[Rob Crittenden]

Tomasz Torcz wrote:

On Sat, Jun 18, 2016 at 11:02:23PM -0400, Rob Crittenden wrote:


Most of the functions work, but 5) I cannot get Authentication→Certificates
list:

On okda, going to Certificates list yields ”Certificate operation cannot be 
completed: Unable to communicate with CMS (Internal Server Error)”
and error_log contains:
[Sat Jun 18 18:59:10.523796 2016] [wsgi:error] [pid 748083] 
falsefalsefalsefalsefalsetruefalsefalsefalsefalsefalsefalse
[Sat Jun 18 18:59:11.244206 2016] [wsgi:error] [pid 748083] ipa: DEBUG: HTTP 
Response code: 500
[Sat Jun 18 18:59:11.248305 2016] [wsgi:error] [pid 748083] ipa: ERROR: 
ipaserver.plugins.dogtag.ra.find(): Unable to communicate with CMS (Internal 
Server Error)
[Sat Jun 18 18:59:11.336576 2016] [wsgi:error] [pid 748083] ipa: DEBUG: WSGI 
wsgi_execute PublicError: Traceback (most recent call last):
[Sat Jun 18 18:59:11.336895 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 350, in 
wsgi_execute
[Sat Jun 18 18:59:11.337011 2016] [wsgi:error] [pid 748083] result = 
self.Command[name](*args, **options)
[Sat Jun 18 18:59:11.337086 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 446, in __call__
[Sat Jun 18 18:59:11.337156 2016] [wsgi:error] [pid 748083] ret = 
self.run(*args, **options)
[Sat Jun 18 18:59:11.337241 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 763, in run
[Sat Jun 18 18:59:11.337311 2016] [wsgi:error] [pid 748083] return 
self.execute(*args, **options)
[Sat Jun 18 18:59:11.337373 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 819, in execute
[Sat Jun 18 18:59:11.337417 2016] [wsgi:error] [pid 748083] 
result=self.Backend.ra.find(options)
[Sat Jun 18 18:59:11.337455 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1861, in 
find
[Sat Jun 18 18:59:11.337493 2016] [wsgi:error] [pid 748083] detail=e.msg)
[Sat Jun 18 18:59:11.337566 2016] [wsgi:error] [pid 748083]   File 
"/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1331, in 
raise_certificate_operation_error
[Sat Jun 18 18:59:11.337653 2016] [wsgi:error] [pid 748083] raise 
errors.CertificateOperationError(error=err_msg)
[Sat Jun 18 18:59:11.337717 2016] [wsgi:error] [pid 748083] 
CertificateOperationError: Certificate operation cannot be completed: Unable to 
communicate with CMS (Internal Server Error)
[Sat Jun 18 18:59:11.337770 2016] [wsgi:error] [pid 748083]
[Sat Jun 18 18:59:11.338805 2016] [wsgi:error] [pid 748083] ipa: INFO: 
[jsonserver_session] ad...@pipebreaker.pl: cert_find(version=u'2.164'): 
CertificateOperationError

How to fix those?


You'll need to look at the dogtag debug log for the reason it threw a 500,
it's in /var/log/pki-tomcat/ca or something close to that.



   I've looked into the logs but I'm not wiser.  Is there a setting to get
rid of java traceback from logs and get more useful messages?  There seem
to be a problem with SSL connection to port 636, maybe because it seems to use
expired certificate?


Not that I know of. The debug log is sure a firehose but you've 
identified the problem.



$ echo | openssl s_client  -connect okda.pipebreaker.pl:636  | openssl x509 
-noout
depth=1 O = PIPEBREAKER.PL, CN = Certificate Authority
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
verify error:num=10:certificate has expired
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
depth=0 O = PIPEBREAKER.PL, CN = okda.pipebreaker.pl
notAfter=Nov 17 12:19:28 2015 GMT
verify return:1
DONE


Run getcert list and look at the expiration dates. What you want to do 
is kill ntpd, set the date back to say a week before the oldest date, 
restart the dirsrv, restart the pki-tomcat/pki-cad service then restart 
certmonger. This should force a renewal attempt.


Use getcert and syslog to watch progress. It may require a few restarts 
of certmonger to get all the certs renewed.


Ideally that all happens fairly gracefully so then you move forward in 
time again, run ipactl restart and things work as usual.


rob





Log from /var/log/pki/pki-tomcat/ca/system:

0.localhost-startStop-1 - [18/Jun/2016:18:54:09 CEST] [8] [3] In Ldap (bound) 
connection pool to host okda.pipebreaker.pl port 636, Cannot connect to LDAP 
server. Error: netscape.ldap.LDAPException: IO Error creating JSS SSL Socket 
(-1)



Log from /var/log/pki/pki-tomcat/ca/debug:

[18/Jun/2016:18:54:03][localhost-startStop-1]: 

[18/Jun/2016:18:54:03][localhost-startStop-1]: =  DEBUG SUBSYSTEM 
INITIALIZED   ===
[18/Jun/2016:18:54:03][localhost-startStop-1]: 

[18/Jun/2016:18:54:03][localhost-startStop-1]: CMSEngine: restart at 
autoShutdown? false

Re: [Freeipa-users] CA: IPA certificates not renewing

[Rob Crittenden]

Marc Wiatrowski wrote:

Thanks for the reply Rob,

So should fixing replication be more than running a re-initialize?
I've tried this with no luck.  Still the same errors in renewing the IPA
certs.


re-init drops one database and replaces it with another. If you really 
did that then you have potentially lost a ton of records if indeed 
replication was stalled. Knowing what commands you ran would help to 
know for sure.



status: CA_UNREACHABLE
ca-error: Server at https://spider01a.iglass.net/ipa/xml failed request,
will retry: 4301 (RPC failed at server.  Certificate operation cannot be
completed: EXCEPTION (Certificate serial number 0x3ffe000f not found))

Is there a procedure for getting these serial numbers back in to the
system? or manually recreating somehow?


When IPA gets a certificate request and the host/service it is 
requesting it for already has a certificate, a revocation is done on the 
existing certificate (which in this case is failing because the cert is 
unknown). If you wipe out the usercertificate field from  the entry 
ldap/spider01a.iglass.net then that should do it.




I was able to clear 4301 error.  One ipaCert needed to be updated.


Great!

rob



thanks

On Thu, Jun 16, 2016 at 10:22 AM, Rob Crittenden > wrote:

Marc Wiatrowski wrote:

Thanks Rob,

Any suggestions on how make the CA aware of the current serial
number?


Serial numbers are dolled out like uid numbers, by the 389-ds DNA
Plugin. So each CA that has ever issued a certificate has its own
range, hence the quite different serial number values.

Given that some issued certificates are unknown it stands to reason
that replication is broken between one or more masters. Fixing that
should resolve (most of) the other issues.

Also started seeing the following error from two of the servers,
spider01b and spider01o, but not spider01a when to navigate in
the web
gui.  Though it doesn't appear to stop me from doing anything.

IPA Error 4301
Certificate operation cannot be completed: EXCEPTION (Invalid
Crential.)


Dogtag does some of its access control by comparing the incoming
client certificate with an expected value in its LDAP database, in
this case uid=ipara,ou=People,o=ipaca. There you'll find a copy of
the client certificate and a description field that contains the
expected serial #, subject and issuer.

These are out-of-whack if you're getting Invalid Credentials. It
could be a number of things so I'd proceed cautiously. Given you
have a working master I'd use that as a starting point.

Look at the the RA cert is in /etc/httpd/alias:

# certutil -L -d /etc/httpd/alias -n ipaCert | grep Serial

See if it is the same on all masters, it should be.

If it is, look at the uid=ipara entry on all the masters. Again,
should be the same.

Note that fixing this won't address any replication issues.

rob


Marc

On Tue, Jun 14, 2016 at 2:07 PM, Marc Wiatrowski 
>> wrote:



 On Tue, Jun 14, 2016 at 11:22 AM, Rob Crittenden
 
>> wrote:

 Marc Wiatrowski wrote:

 Hello, I'm having issues with the 3 ipa
certificates of type
 CA: IPA
 renewing on 2 of 3 replicas.  Particularly on the 2
that are
 not the CA
 master.  The other 5 certificates from getcert list
do renew
 and all
 certificates on the CA master do look to renew.

 Both servers running
 ipa-server-3.0.0-50.el6.centos.1.x86_64  I've done
 full updates and rebooted.


 Can you check on the replication status for each CA?

 $ ipa-csreplica-manage list -v ipa.example.com

 

 The hostname is important because including that will
show the
 agreements that host has. Do this for each master with
a CA.

 The CA being asked to do the renewal is unaware of the
current
 serial number so it is refusing to proceed.

 rob



 [root@spider01o]$ ipa-csreplica-manage list -v
spider01a.iglass.net 
 
 Directory Manager password:

spider01b.iglass.net 

last init status: None

Re: [Freeipa-users] CentOS 6.8: uninstalling IPA client causes python error

[Rob Crittenden]

dan.finkelst...@high5games.com wrote:

Oh, I disabled that first. I turn on services and restrictions
one-by-one after things are working, not before.


I guess brute force via strace then. Something is throwing a permission 
error.


rob



—Dan



*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com _| 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com 

Play High 5 Casino  and Shake
the Sky 

Follow us on: Facebook , Twitter
, YouTube
, Linkedin


//

/This message and any attachments may contain confidential or privileged
information and are only for the use of the intended recipient of this
message. If you are not the intended recipient, please notify the sender
by return email, and delete or destroy this and all copies of this
message and all attachments. Any unauthorized disclosure, use,
distribution, or reproduction of this message or any attachments is
prohibited and may be unlawful./

*From: *Rob Crittenden 
*Date: *Saturday, June 18, 2016 at 23:00
*To: *Daniel Finkestein ,
"freeipa-users@redhat.com" 
*Subject: *Re: [Freeipa-users] CentOS 6.8: uninstalling IPA client
causes python error

I'd check for SELinux errors, that might explain things.

rob





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

Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem

[Sean Hogan]

Noticed something else really goofy in the DNS logs on master ipa

client 10.9.0.1#58094: query failed (SERVFAIL) for
serv1.domain.local.domain.local/IN/ at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.10.0.1#44147: query failed (SERVFAIL) for
serv2.in-addr.arpa/IN/PTR at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.10.0.1#56466: query failed (SERVFAIL) for
serv2.in-addr.arpa/IN/PTR at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.110.0.1#53367: query failed (SERVFAIL) for
serv3.domain.local.domain.local/IN/A at query.c:6569
timeout in ldap_pool_getconnection(): try to raise 'connections' parameter;
potential deadlock?
client 10.110.0.1#53367: query failed (SERVFAIL) for
serv3.domain.local.domain.local/IN/ at query.c:6569

 On a replica I see this
[bob@replica2 data]# tail -f named.run
dispatch 0x7f408c187970: open_socket(0.0.0.0#1935) -> permission denied:
continuing
dispatch 0x7f408c187970: open_socket(0.0.0.0#8610) -> permission denied:
continuing
dispatch 0x7f408c187970: open_socket(0.0.0.0#6514) -> permission denied:
continuing
dispatch 0x7f408c187970: open_socket(0.0.0.0#8610) -> permission denied:
continuing
dispatch 0x7f408c187970: open_socket(0.0.0.0#1935) -> permission denied:
continuing


Feel like I am caught in a troubleshooting loop being to close to it.. has
anyone seen this before?


Sean Hogan







From:   Sean Hogan/Durham/IBM
To: Sean Hogan/Durham/IBM@IBMUS
Cc: freeipa-users 
Date:   06/20/2016 12:49 PM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem


Also seeing this in the upgrade log on the first master but not on the 7
ipas.

ERROR Failed to restart named: Command '/sbin/service named restart '
returned non-zero exit status 7


which led me to

https://bugzilla.redhat.com/show_bug.cgi?id=895298





Sean Hogan







From:   Sean Hogan/Durham/IBM@IBMUS
To: freeipa-users 
Date:   06/20/2016 11:46 AM
Subject:Re: [Freeipa-users] IPA 3.0.47 to 3.0.50 Upgrade problem
Sent by:freeipa-users-boun...@redhat.com



Hi All..

I thought we fixed this issue by rebooting the KVM host but it is showing
again. Our First Master IPA is being rebooted 2 -5 times a day now just to
keep it alive.

What we are seeing:

God@FirstMaster log]# kinit admin
kinit: Cannot contact any KDC for realm 'Domain.LOCAL' while getting
initial credentials

DNS is not working as nslookup is failing to a replica think once we
lose DNS it all goes down hill which makes sense.

[god@FirstMaster log]# ipactl stop -> Just hangs forever.. no replies..
no error.. nothing

I try service named stop and nothing happens

I have the box hard shutdown from KVM console. Reboot it and it works for a
little while but eventually back to same behavior.

At this point I can service named stop and it responds... ipactl status and
it responds.. but when if I try service named restart I get

[god@FirstMaster log]# service named stop
Stopping named: ..

[god@Firstmaster log]# service named start
Starting named: [FAILED]

[god@FirstMaster log]# service named status
rndc: connect failed: 127.0.0.1#953: connection refused
named dead but pid file exists

Rebooted box and it is hung on shutting down domain-local and never fully
shuts down.. have to get it hard shutdown again.
During an attempt to gracefully shut down we see this

Shutting Down dirsrv:
PKI-IPA OK
DOMAIN-LOCAL FAILED
*** Error: 1 instance(s) unsuccessfully stopped FAILED

Then it moves on to shut other things down and returns to dirsrv
Shutting Down dirsrv:
PKI-IPAserver already stopped FAILED {Makes sense.. it died earlier}
DOMAIN-LOCAL... {this sits here til we hard shutdown}



bind-libs-9.8.2-0.47.rc1.el6.x86_64
bind-9.8.2-0.47.rc1.el6.x86_64
bind-utils-9.8.2-0.47.rc1.el6.x86_64


ipa-client-3.0.0-50.el6.1.x86_64
ipa-server-selinux-3.0.0-50.el6.1.x86_64
ipa-server-3.0.0-50.el6.1.x86_64
sssd-ipa-1.13.3-22.el6.x86_64


/var/log/dirsrv/slapd-DOMAIN-LOCAL
[20/Jun/2016:13:29:06 -0400] - 389-Directory/1.2.11.15 B2016.063.2110
starting up
[20/Jun/2016:13:29:06 -0400] schema-compat-plugin - warning: no entries set
up under cn=computers, cn=compat,dc=domain,dc=local
[20/Jun/2016:13:29:07 -0400] NSMMReplicationPlugin - ruv_compare_ruv: RUV
[database RUV] does not contain element [{replica 7} 55ca26a90007
5688d8e60017] which is present in RUV [changelog max RUV]
[20/Jun/2016:13:29:07 -0400] NSMMReplicationPlugin -
replica_check_for_data_reload: Warning: for replica dc=domain,dc=local
there were some differences between the changelog max RUV and the database
RUV. If there are obsolete elements in the database RUV, you should remove
them using the CLEANALLRUV task. If they are not obsolete, you should check
their status to see 

Re: [Freeipa-users] OS X Yosemite unable to authenticate

[Joe DiTommasso]

You don't have to add them as an administrator for login to work, just
sudo. Will send one over in a second.

On Tue, Jun 21, 2016 at 12:11 PM, Cal Sawyer  wrote:

>  ... "have to add the user as an administrator on
> the local machine"?  That's pretty intriguing, but not great security-wise,
> unfortunately.  Not a big deal at the moment, though
>
> ok, just made my user account an admin but it's still dragging on login.
>
> My IPA setup is the same: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
> Any chance i could get a denatured plist from you offline, Joe?
>
> cheers
>
> Cal Sawyer | Systems Engineer | BlueBolt Ltd
> 15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | www.blue-bolt.com
>
> On 21/06/16 16:07, Joe DiTommasso wrote:
>
> No fiddling that I remember. Basically got the setup working once and then
> have been pushing out plist files to all new installs. Graphical login
> works, as does sudo, sort of-still have to add the user as an administrator
> on the local machine, but then their kerberos password works for
> authentication. Running up-to-date-ish IPA 4 on CentOS 7.
>
> jdito@sum-freeipa-01:~$ rpm -qa | grep ipa
>
> *ipa*-python-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
> lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64
>
> *ipa*-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
> python-in*ipa*rse-0.4-9.el7.noarch
>
> *ipa*-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
> sssd-*ipa*-1.13.0-40.el7_2.4.x86_64
>
> *ipa*-client-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
> python-lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64
>
> *ipa*-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64
>
>
> Let me know what you'd like to see from my config. Thanks for the tip on
> the secondary groups-I already had that in there, but looking at it
> realized that I needed to point at the compat tree, because the regular one
> doesn't expose memberUID.
>
> On Tue, Jun 21, 2016 at 10:42 AM, Cal Sawyer  wrote:
>
>> Wow, that's surprising, Joe.  I'm also using the linsec recipe. Yours
>> required no fiddling?   You can login straight off from the graphical
>> loginWindow?
>>
>> Yes, very interested in any help you can offer.  Are you authenticating
>> against IPA 3 or 4, for sake of curiosity.
>>
>> BTW:  you can get your secondary groups by:
>>
>> In Groups add attribute 'GroupMembership' mapped to 'memberUID'
>>
>> thanks!
>>
>> Cal Sawyer | Systems Engineer | BlueBolt Ltd
>> 15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | www.blue-bolt.com
>>
>> On 21/06/16 15:07, Joe DiTommasso wrote:
>>
>> I've actually got a whole stack of El Capitan clients authenticating
>> against FreeIPA:
>>
>> mac-mini-01:~ jdito$ system_profiler SPSoftwareDataType
>> Software:
>>
>> System Software Overview:
>>
>>   System Version: OS X 10.11.5 (15F34)
>>   Kernel Version: Darwin 15.5.0
>>   Boot Volume: Macintosh HD
>>   Boot Mode: Normal
>>   Computer Name: admin’s Mac mini
>>   User Name: Joe DiTommasso (jdito)
>>   Secure Virtual Memory: Enabled
>>   System Integrity Protection: Enabled
>>   Time since boot: 14 days 15:00
>>
>> The Linsec guide worked for me. The only real issue is that it only sees
>> the user's primary group, and not supplemental groups. I'm not terribly
>> good with Macs, but happy to assist in troubleshooting.
>>
>> Joe
>>
>> On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer < 
>> ca...@blue-bolt.com> wrote:
>>
>>> As usual, apologies for any formatting issues due to extracting message
>>> threads out of digests ...
>>>
>>> Anyhow., i have determined where everything goes terribly wrong with OSX
>>> clients:  OSX 10.10.3 ("out of the box" Yosemite) works fine using
>>> linsec.ca's guidance.  However, the second you patch to 10.10.5 or
>>> upgrade to El Capitan (10.11.5), authentication fails absolutely in the
>>> ways described in earlier threads.  Colleagues who i've spoken with who are
>>> trying to set up IPA at their facilities report the same problem and it's a
>>> total show-stopper.  Interesting how all(?) of what is written on the topic
>>> of OSX and IPA dries up after 10.8, although we've seen in an earlier
>>> thread reports of 10.9 working.  I've repeated this test a few times and
>>> the result is always the same. - 10.10.3 is the last OSX capable of
>>> authenticating against IPA using currently available knowledge.
>>>
>>> Running tcpdump on 10.10.3 and a 10.10.5 clients show very different
>>> authentication dialogues.  I'm afraid, however, that i lack the skills to
>>> interpret where exactly the later OSX release is failing. I have my
>>> (unfounded) suspicions - that SASL binding for LDAP and kerberos are
>>> implicated. 10.10.3 certainly shows no kerberos transactions whereas 10.10.5
>>>
>>> Re DNS: both client types resolve all SRV records hosted in IPA fine.  I
>>> even went so far as setting up rudimentary ipv6 as there were some 
>>> requests that were going unanswered and it thought it might 

Re: [Freeipa-users] OS X Yosemite unable to authenticate

[Cal Sawyer]

 ... "have to add the user as an administrator on 
the local machine"?  That's pretty intriguing, but not great 
security-wise, unfortunately.  Not a big deal at the moment, though


ok, just made my user account an admin but it's still dragging on login.

My IPA setup is the same: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64

Any chance i could get a denatured plist from you offline, Joe?

cheers

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 | www.blue-bolt.com

On 21/06/16 16:07, Joe DiTommasso wrote:
No fiddling that I remember. Basically got the setup working once and 
then have been pushing out plist files to all new installs. Graphical 
login works, as does sudo, sort of-still have to add the user as an 
administrator on the local machine, but then their kerberos password 
works for authentication. Running up-to-date-ish IPA 4 on CentOS 7.


jdito@sum-freeipa-01:~$ rpm -qa | grep ipa

*ipa*-python-4.2.0-15.0.1.el7.centos.6.1.x86_64

lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64

*ipa*-server-4.2.0-15.0.1.el7.centos.6.1.x86_64

python-in*ipa*rse-0.4-9.el7.noarch

*ipa*-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64

sssd-*ipa*-1.13.0-40.el7_2.4.x86_64

*ipa*-client-4.2.0-15.0.1.el7.centos.6.1.x86_64

python-lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64

*ipa*-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64


Let me know what you'd like to see from my config. Thanks for the tip 
on the secondary groups-I already had that in there, but looking at it 
realized that I needed to point at the compat tree, because the 
regular one doesn't expose memberUID.



On Tue, Jun 21, 2016 at 10:42 AM, Cal Sawyer > wrote:


Wow, that's surprising, Joe.  I'm also using the linsec recipe.
Yours required no fiddling?   You can login straight off from the
graphical loginWindow?

Yes, very interested in any help you can offer.  Are you
authenticating against IPA 3 or 4, for sake of curiosity.

BTW:  you can get your secondary groups by:

In Groups add attribute 'GroupMembership' mapped to 'memberUID'

thanks!

Cal Sawyer | Systems Engineer | BlueBolt Ltd 15-16 Margaret Street
| London W1W 8RW +44 (0)20 7637 5575
  |www.blue-bolt.com 


On 21/06/16 15:07, Joe DiTommasso wrote:

I've actually got a whole stack of El Capitan clients
authenticating against FreeIPA:

mac-mini-01:~ jdito$ system_profiler SPSoftwareDataType
Software:

System Software Overview:

  System Version: OS X 10.11.5 (15F34)
  Kernel Version: Darwin 15.5.0
  Boot Volume: Macintosh HD
  Boot Mode: Normal
  Computer Name: admin’s Mac mini
  User Name: Joe DiTommasso (jdito)
  Secure Virtual Memory: Enabled
  System Integrity Protection: Enabled
  Time since boot: 14 days 15:00

The Linsec guide worked for me. The only real issue is that it
only sees the user's primary group, and not supplemental groups.
I'm not terribly good with Macs, but happy to assist in
troubleshooting.

Joe

On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer > wrote:

As usual, apologies for any formatting issues due to
extracting message threads out of digests ...

Anyhow., i have determined where everything goes terribly
wrong with OSX clients:  OSX 10.10.3 ("out of the box"
Yosemite) works fine using linsec.ca 's
guidance.  However, the second you patch to 10.10.5 or
upgrade to El Capitan (10.11.5), authentication fails
absolutely in the ways described in earlier threads. 
Colleagues who i've spoken with who are trying to set up IPA

at their facilities report the same problem and it's a total
show-stopper. Interesting how all(?) of what is written on
the topic of OSX and IPA dries up after 10.8, although we've
seen in an earlier thread reports of 10.9 working.  I've
repeated this test a few times and the result is always the
same. - 10.10.3 is the last OSX capable of authenticating
against IPA using currently available knowledge.

Running tcpdump on 10.10.3 and a 10.10.5 clients show very
different authentication dialogues.  I'm afraid, however,
that i lack the skills to interpret where exactly the later
OSX release is failing. I have my (unfounded) suspicions -
that SASL binding for LDAP and kerberos are implicated.
10.10.3 certainly shows no kerberos transactions whereas 10.10.5

Re DNS: both client types resolve all SRV records hosted in
IPA fine.  I even went so far as setting up rudimentary ipv6
as there were some  requests that were going unanswered
and it thought it might related 

Re: [Freeipa-users] Replication time and relation to cache size

[Ash Alam]

anyone have any thoughts on this?

Thank You

On Fri, Jun 10, 2016 at 2:59 PM, Ash Alam  wrote:

> Hello
>
> I have been going through the lists but i have not found the answer i am
> looking for. I am seeing few issues for which i am looking for some
> clarification.
>
> 1. What is the relationship between replication time and cache size?
>
> - I am noticing that it's taking up to 5 minutes for some things to
> replication when change is made on one node and there are two additional
> masters. The ipa nodes are all virtual machines within the same cluster.
>
> - WARNING: changelog: entry cache size 2097152B is less than db size
> 116154368B; We recommend to increase the entry cache size
> nsslapd-cachememsize.
>
> - I don't understand the cache size. Would't increasing it cause the same
> issue when we hit the new limit?
>
> - connection - conn=3779 fd=175 Incoming BER Element was 3 bytes, max
> allowable is 209715200 bytes. Change the nsslapd-maxbersize attribute in
> cn=config to increase.
>
>
> 2. Is there a definitive solution to this error? This seems to pop up
> every so often.
>
> - NSMMReplicationPlugin - agmt="cn=meToipa009.pp" (ipa009:389): Warning:
> Attempting to release replica, but unable to receive endReplication
> extended operation response from the replica. Error -5 (Timed out)
>
>
> Thank You
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] OS X Yosemite unable to authenticate

[Joe DiTommasso]

No fiddling that I remember. Basically got the setup working once and then
have been pushing out plist files to all new installs. Graphical login
works, as does sudo, sort of-still have to add the user as an administrator
on the local machine, but then their kerberos password works for
authentication. Running up-to-date-ish IPA 4 on CentOS 7.

jdito@sum-freeipa-01:~$ rpm -qa | grep ipa

*ipa*-python-4.2.0-15.0.1.el7.centos.6.1.x86_64

lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64

*ipa*-server-4.2.0-15.0.1.el7.centos.6.1.x86_64

python-in*ipa*rse-0.4-9.el7.noarch

*ipa*-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64

sssd-*ipa*-1.13.0-40.el7_2.4.x86_64

*ipa*-client-4.2.0-15.0.1.el7.centos.6.1.x86_64

python-lib*ipa*_hbac-1.13.0-40.el7_2.4.x86_64

*ipa*-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64


Let me know what you'd like to see from my config. Thanks for the tip on
the secondary groups-I already had that in there, but looking at it
realized that I needed to point at the compat tree, because the regular one
doesn't expose memberUID.

On Tue, Jun 21, 2016 at 10:42 AM, Cal Sawyer  wrote:

> Wow, that's surprising, Joe.  I'm also using the linsec recipe. Yours
> required no fiddling?   You can login straight off from the graphical
> loginWindow?
>
> Yes, very interested in any help you can offer.  Are you authenticating
> against IPA 3 or 4, for sake of curiosity.
>
> BTW:  you can get your secondary groups by:
>
> In Groups add attribute 'GroupMembership' mapped to 'memberUID'
>
> thanks!
>
> Cal Sawyer | Systems Engineer | BlueBolt Ltd
> 15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | www.blue-bolt.com
>
> On 21/06/16 15:07, Joe DiTommasso wrote:
>
> I've actually got a whole stack of El Capitan clients authenticating
> against FreeIPA:
>
> mac-mini-01:~ jdito$ system_profiler SPSoftwareDataType
> Software:
>
> System Software Overview:
>
>   System Version: OS X 10.11.5 (15F34)
>   Kernel Version: Darwin 15.5.0
>   Boot Volume: Macintosh HD
>   Boot Mode: Normal
>   Computer Name: admin’s Mac mini
>   User Name: Joe DiTommasso (jdito)
>   Secure Virtual Memory: Enabled
>   System Integrity Protection: Enabled
>   Time since boot: 14 days 15:00
>
> The Linsec guide worked for me. The only real issue is that it only sees
> the user's primary group, and not supplemental groups. I'm not terribly
> good with Macs, but happy to assist in troubleshooting.
>
> Joe
>
> On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer  wrote:
>
>> As usual, apologies for any formatting issues due to extracting message
>> threads out of digests ...
>>
>> Anyhow., i have determined where everything goes terribly wrong with OSX
>> clients:  OSX 10.10.3 ("out of the box" Yosemite) works fine using
>> linsec.ca's guidance.  However, the second you patch to 10.10.5 or
>> upgrade to El Capitan (10.11.5), authentication fails absolutely in the
>> ways described in earlier threads.  Colleagues who i've spoken with who are
>> trying to set up IPA at their facilities report the same problem and it's a
>> total show-stopper.  Interesting how all(?) of what is written on the topic
>> of OSX and IPA dries up after 10.8, although we've seen in an earlier
>> thread reports of 10.9 working.  I've repeated this test a few times and
>> the result is always the same. - 10.10.3 is the last OSX capable of
>> authenticating against IPA using currently available knowledge.
>>
>> Running tcpdump on 10.10.3 and a 10.10.5 clients show very different
>> authentication dialogues.  I'm afraid, however, that i lack the skills to
>> interpret where exactly the later OSX release is failing. I have my
>> (unfounded) suspicions - that SASL binding for LDAP and kerberos are
>> implicated. 10.10.3 certainly shows no kerberos transactions whereas 10.10.5
>>
>> Re DNS: both client types resolve all SRV records hosted in IPA fine.  I
>> even went so far as setting up rudimentary ipv6 as there were some 
>> requests that were going unanswered and it thought it might related (not,
>> as it turns out)
>>
>> So, would anyone on the IPA team be interested in looking at some packet
>> captures?  I'm completely up for working with you, providing whatever is
>> needed and doing testing.  It would be fantastic to restore IPA-based auth
>> for newer OSX releases.
>>
>> best regards,
>>
>> - cal sawyer
>>
>> From: John Obaterspok  
>> To: Nicola Canepa  
>> Cc: "freeipa-users@redhat.com"  
>>  , Cal Sawyer
>>   
>>
>> Hi, Are you only having problems to login to login to OSX with the IPA
>> user now? If that is the case then check the DNS settings you are using and
>> make sure the IPA server is listed first and that it has full name. Exactly
>> the same problem occurred for 

Re: [Freeipa-users] OS X Yosemite unable to authenticate

[Cal Sawyer]

Wow, that's surprising, Joe.  I'm also using the linsec recipe. Yours 
required no fiddling?   You can login straight off from the graphical 
loginWindow?


Yes, very interested in any help you can offer.  Are you authenticating 
against IPA 3 or 4, for sake of curiosity.


BTW:  you can get your secondary groups by:

In Groups add attribute 'GroupMembership' mapped to 'memberUID'

thanks!

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW
+44 (0)20 7637 5575 | www.blue-bolt.com

On 21/06/16 15:07, Joe DiTommasso wrote:
I've actually got a whole stack of El Capitan clients authenticating 
against FreeIPA:


mac-mini-01:~ jdito$ system_profiler SPSoftwareDataType
Software:

System Software Overview:

  System Version: OS X 10.11.5 (15F34)
  Kernel Version: Darwin 15.5.0
  Boot Volume: Macintosh HD
  Boot Mode: Normal
  Computer Name: admin’s Mac mini
  User Name: Joe DiTommasso (jdito)
  Secure Virtual Memory: Enabled
  System Integrity Protection: Enabled
  Time since boot: 14 days 15:00

The Linsec guide worked for me. The only real issue is that it only 
sees the user's primary group, and not supplemental groups. I'm not 
terribly good with Macs, but happy to assist in troubleshooting.


Joe

On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer > wrote:


As usual, apologies for any formatting issues due to extracting
message threads out of digests ...

Anyhow., i have determined where everything goes terribly wrong
with OSX clients:  OSX 10.10.3 ("out of the box" Yosemite) works
fine using linsec.ca 's guidance.  However, the
second you patch to 10.10.5 or upgrade to El Capitan (10.11.5),
authentication fails absolutely in the ways described in earlier
threads. Colleagues who i've spoken with who are trying to set up
IPA at their facilities report the same problem and it's a total
show-stopper.  Interesting how all(?) of what is written on the
topic of OSX and IPA dries up after 10.8, although we've seen in
an earlier thread reports of 10.9 working.  I've repeated this
test a few times and the result is always the same. - 10.10.3 is
the last OSX capable of authenticating against IPA using currently
available knowledge.

Running tcpdump on 10.10.3 and a 10.10.5 clients show very
different authentication dialogues.  I'm afraid, however, that i
lack the skills to interpret where exactly the later OSX release
is failing. I have my (unfounded) suspicions - that SASL binding
for LDAP and kerberos are implicated. 10.10.3 certainly shows no
kerberos transactions whereas 10.10.5

Re DNS: both client types resolve all SRV records hosted in IPA
fine.  I even went so far as setting up rudimentary ipv6 as there
were some  requests that were going unanswered and it thought
it might related (not, as it turns out)

So, would anyone on the IPA team be interested in looking at some
packet captures?  I'm completely up for working with you,
providing whatever is needed and doing testing. It would be
fantastic to restore IPA-based auth for newer OSX releases.

best regards,

- cal sawyer

From: John Obaterspok 

To: Nicola Canepa 
Cc:"freeipa-users@redhat.com"   
 ,  Cal Sawyer
 

Hi, Are you only having problems to login to login to OSX
with the IPA user now? If that is the case then check the
DNS settings you are using and make sure the IPA server is
listed first and that it has full name. Exactly the same
problem occurred for me with the slow logins to OSX which
was due to the DNS settings and that OSX only used short
name of IPA server during login (if I logged in as local
user I could ping and lookup hosts using short name) --
john 2015-12-21 17:49 GMT+01:00 Nicola Canepa
 :

I had to configure /etc/krb5.conf, and to avoid the requested 
reboot, I
did a "dscacheutil -flushcache", both as the logged in user and as 
root.
I tried enabling the anonymous bind and now also the directory 
browser
(and all the login process) works as expected.

Nicola

Il 21/12/15 17:39, Cal Sawyer ha scritto:

Thanks, John and Nicola

Kerberos occurred to me as well late in the day yesterday.  Happily 
(?),
knit works fine simply specifying the user in question with no need 
to
suffix with the kerberos realm

   

Re: [Freeipa-users] OS X Yosemite unable to authenticate

[Joe DiTommasso]

I've actually got a whole stack of El Capitan clients authenticating
against FreeIPA:

mac-mini-01:~ jdito$ system_profiler SPSoftwareDataType
Software:

System Software Overview:

  System Version: OS X 10.11.5 (15F34)
  Kernel Version: Darwin 15.5.0
  Boot Volume: Macintosh HD
  Boot Mode: Normal
  Computer Name: admin’s Mac mini
  User Name: Joe DiTommasso (jdito)
  Secure Virtual Memory: Enabled
  System Integrity Protection: Enabled
  Time since boot: 14 days 15:00

The Linsec guide worked for me. The only real issue is that it only sees
the user's primary group, and not supplemental groups. I'm not terribly
good with Macs, but happy to assist in troubleshooting.

Joe

On Tue, Jun 21, 2016 at 9:46 AM, Cal Sawyer  wrote:

> As usual, apologies for any formatting issues due to extracting message
> threads out of digests ...
>
> Anyhow., i have determined where everything goes terribly wrong with OSX
> clients:  OSX 10.10.3 ("out of the box" Yosemite) works fine using
> linsec.ca's guidance.  However, the second you patch to 10.10.5 or
> upgrade to El Capitan (10.11.5), authentication fails absolutely in the
> ways described in earlier threads.  Colleagues who i've spoken with who are
> trying to set up IPA at their facilities report the same problem and it's a
> total show-stopper.  Interesting how all(?) of what is written on the topic
> of OSX and IPA dries up after 10.8, although we've seen in an earlier
> thread reports of 10.9 working.  I've repeated this test a few times and
> the result is always the same. - 10.10.3 is the last OSX capable of
> authenticating against IPA using currently available knowledge.
>
> Running tcpdump on 10.10.3 and a 10.10.5 clients show very different
> authentication dialogues.  I'm afraid, however, that i lack the skills to
> interpret where exactly the later OSX release is failing. I have my
> (unfounded) suspicions - that SASL binding for LDAP and kerberos are
> implicated. 10.10.3 certainly shows no kerberos transactions whereas 10.10.5
>
> Re DNS: both client types resolve all SRV records hosted in IPA fine.  I
> even went so far as setting up rudimentary ipv6 as there were some 
> requests that were going unanswered and it thought it might related (not,
> as it turns out)
>
> So, would anyone on the IPA team be interested in looking at some packet
> captures?  I'm completely up for working with you, providing whatever is
> needed and doing testing.  It would be fantastic to restore IPA-based auth
> for newer OSX releases.
>
> best regards,
>
> - cal sawyer
>
> From: John Obaterspok  
> To: Nicola Canepa  
> Cc: "freeipa-users@redhat.com"  
>  ,  Cal Sawyer
>    
>
> Hi, Are you only having problems to login to login to OSX with the IPA
> user now? If that is the case then check the DNS settings you are using and
> make sure the IPA server is listed first and that it has full name. Exactly
> the same problem occurred for me with the slow logins to OSX which was due
> to the DNS settings and that OSX only used short name of IPA server during
> login (if I logged in as local user I could ping and lookup hosts using
> short name) -- john 2015-12-21 17:49 GMT+01:00 Nicola Canepa
>  :
>
> I had to configure /etc/krb5.conf, and to avoid the requested reboot, I
> did a "dscacheutil -flushcache", both as the logged in user and as root.
> I tried enabling the anonymous bind and now also the directory browser
> (and all the login process) works as expected.
>
> Nicola
>
> Il 21/12/15 17:39, Cal Sawyer ha scritto:
>
> Thanks, John and Nicola
>
> Kerberos occurred to me as well late in the day yesterday.  Happily (?),
> knit works fine simply specifying the user in question with no need to
> suffix with the kerberos realm
>
> I did find that my test user had an expired password, which i fixed on the
> IPA server.  This was never flagged up under Linux, btw.  It has not change
> anything, however, other than not prompting for password changes that never
> take effect.  Funnily, it expired in the midst of testing - fun.
>
> I was mistaken when i said i was unable to log in - it turns out that it
> takes almost 10 minutes for a login from the frintend to complete - i just
> didn't wait long enough.  10 mins is of course unacceptable :)  "su - user"
> and "login user" fail outright after rejecting accept any user's password
>
> DNS is fine and i can resolve ldap and kerberos SRV records from the Mac
>
> In line with Nicola's experience, i can browse groups and users in the
> Directory Editor and all attributes appear spot on.
>
> Besides modding /etc/pam.d/authorization, adding a corrected
> edu.mit.kerberos to /LibraryPreferences and setting up the directory 
> 

Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

[Petr Spacek]

On 21.6.2016 15:03, dan.finkelst...@high5games.com wrote:
> Solution found (or, if not, a workaround):
> IPA replicas must be named in the root domain/zone and not in a subdomain, 
> else DNS fails to serve records in the root domain. Once we changed our 
> configuration to reflect this, DNS returned to normal.

This is most likely a workaround for some sort of misconfiguration, FreeIPA
itself does not require anything like that.

Petr^2 Spacek


> From:  on behalf of Daniel Finkestein 
> 
> Date: Tuesday, June 21, 2016 at 07:21
> To: "freeipa-users@redhat.com" 
> Subject: Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the 
> top-level domain/zone
> 
> Hi Petr,
> 
> Top level means the root zone of the various DNS trees we serve. For example, 
> h5g.com would be the root and dev.h5g.com, test.h5g.com, etc., would be the 
> subdomains. Our subdomains query fine, but any hosts in the root domain no 
> longer resolve.
> 
> An example of an unresolvable name is IPA itself: ipa.h5g.com. Here's output 
> from dig:
> 
> root@ipa ~]# dig ipa.h5g.com
> 
> ; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> ipa.h5g.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52405
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;ipa.h5g.com.  INA
> 
> ;; Query time: 0 msec
> ;; SERVER: 10.55.10.31#53(10.55.10.31)
> ;; WHEN: Tue Jun 21 07:15:14 EDT 2016
> ;; MSG SIZE  rcvd: 42
> 
> We expect that its IP address returns from dig, but it doesn't.
> 
> We have 100 zones defined, including forward and reverse zones — all active.
> 
> We do use DNS forwarding, but in a very unsophisticated way: we set up the 
> forwarders to go to Google if our DNS can't resolve a name.
> 
> Thanks and regards,
> Dan
> 
> [cid:image002.jpg@01D1CB9B.D6819140]
> Daniel Alex Finkelstein| Lead Dev Ops Engineer
> dan.finkelst...@h5g.com | 212.604.3447
> One World Trade Center, New York, NY 10007
> www.high5games.com
> Play High 5 Casino and Shake the 
> Sky
> Follow us on: Facebook, 
> Twitter, 
> YouTube, 
> Linkedin
> 
> This message and any attachments may contain confidential or privileged 
> information and are only for the use of the intended recipient of this 
> message. If you are not the intended recipient, please notify the sender by 
> return email, and delete or destroy this and all copies of this message and 
> all attachments. Any unauthorized disclosure, use, distribution, or 
> reproduction of this message or any attachments is prohibited and may be 
> unlawful.
> 
> From:  on behalf of Petr Spacek 
> 
> Organization: Red Hat
> Date: Tuesday, June 21, 2016 at 06:04
> To: "freeipa-users@redhat.com" 
> Subject: Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the 
> top-level domain/zone
> 
> On 21.6.2016 11:23, 
> dan.finkelst...@high5games.com wrote:
> We've recently set up a "clean" install of FreeIPA replete with replicas, but 
> we just noticed an odd behavior in the DNS service: hosts in the top level 
> domain (like ipa.example.com) do not resolve, whereas hosts in subdomains 
> (like ipa.dev.example.com) do. I'm not sure what to look for in the various 
> log files but I don't see any obvious errors. I thought perhaps this might 
> have some guidance 
> https://www.redhat.com/archives/freeipa-users/2015-July/msg00102.html, and 
> maybe it does, but I'm not sure how to rescue my top-level domain names.
> 
> Hi,
> 
> we can certainly debug this but first of all, please clarify what 'top-level'
> means.
> 
> If you really want help please do not obfuscate any DNS names. It often hides
> real problems while not improving security in any way. (BTW you do not need to
> hide domain names like 'NY5-EXMB1.High5.local' because these already leaked
> through e-mail headers :-)
> 
> So, here are the important questions:
> 0) What name is unresolvable?
> $ dig the.problematic.name.example.
> 
> 1) What is the expected result from "dig"?
> 
> 2) What DNS zones are configured in IPA?
> $ ipa dnszone-find
> 
> 3) Do you use DNS forwarding? (--forwarders option during IPA install or
> commands ipa dnsforwardzone-*, ipa dnsconfig-mod etc.)

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

Re: [Freeipa-users] OS X Yosemite unable to authenticate

[Cal Sawyer]

As usual, apologies for any formatting issues due to extracting message 
threads out of digests ...


Anyhow., i have determined where everything goes terribly wrong with OSX 
clients:  OSX 10.10.3 ("out of the box" Yosemite) works fine using 
linsec.ca's guidance.  However, the second you patch to 10.10.5 or 
upgrade to El Capitan (10.11.5), authentication fails absolutely in the 
ways described in earlier threads.  Colleagues who i've spoken with who 
are trying to set up IPA at their facilities report the same problem and 
it's a total show-stopper.  Interesting how all(?) of what is written on 
the topic of OSX and IPA dries up after 10.8, although we've seen in an 
earlier thread reports of 10.9 working.  I've repeated this test a few 
times and the result is always the same. - 10.10.3 is the last OSX 
capable of authenticating against IPA using currently available knowledge.


Running tcpdump on 10.10.3 and a 10.10.5 clients show very different 
authentication dialogues.  I'm afraid, however, that i lack the skills 
to interpret where exactly the later OSX release is failing. I have my 
(unfounded) suspicions - that SASL binding for LDAP and kerberos are 
implicated. 10.10.3 certainly shows no kerberos transactions whereas 10.10.5


Re DNS: both client types resolve all SRV records hosted in IPA fine.  I 
even went so far as setting up rudimentary ipv6 as there were some  
requests that were going unanswered and it thought it might related 
(not, as it turns out)


So, would anyone on the IPA team be interested in looking at some packet 
captures?  I'm completely up for working with you, providing whatever is 
needed and doing testing.  It would be fantastic to restore IPA-based 
auth for newer OSX releases.


best regards,

- cal sawyer

   From: John Obaterspok
   To: Nicola Canepa
   Cc:"freeipa-users@redhat.com"  ,   Cal Sawyer


   Hi, Are you only having problems to login to login to OSX with
   the IPA user now? If that is the case then check the DNS
   settings you are using and make sure the IPA server is listed
   first and that it has full name. Exactly the same problem
   occurred for me with the slow logins to OSX which was due to the
   DNS settings and that OSX only used short name of IPA server
   during login (if I logged in as local user I could ping and
   lookup hosts using short name) -- john 2015-12-21 17:49
   GMT+01:00 Nicola Canepa :

I had to configure /etc/krb5.conf, and to avoid the requested reboot, I
did a "dscacheutil -flushcache", both as the logged in user and as root.
I tried enabling the anonymous bind and now also the directory browser
(and all the login process) works as expected.

Nicola

Il 21/12/15 17:39, Cal Sawyer ha scritto:

Thanks, John and Nicola

Kerberos occurred to me as well late in the day yesterday.  Happily (?),
knit works fine simply specifying the user in question with no need to
suffix with the kerberos realm

I did find that my test user had an expired password, which i fixed on 
the
IPA server.  This was never flagged up under Linux, btw.  It has not 
change
anything, however, other than not prompting for password changes that 
never
take effect.  Funnily, it expired in the midst of testing - fun.

I was mistaken when i said i was unable to log in - it turns out that it
takes almost 10 minutes for a login from the frintend to complete - i 
just
didn't wait long enough.  10 mins is of course unacceptable :)  "su - 
user"
and "login user" fail outright after rejecting accept any user's 
password

DNS is fine and i can resolve ldap and kerberos SRV records from the Mac

In line with Nicola's experience, i can browse groups and users in the
Directory Editor and all attributes appear spot on.

Besides modding /etc/pam.d/authorization, adding a corrected
edu.mit.kerberos to /LibraryPreferences and setting up the directory per
linsec.ca, can anyone think of something i may have missed?  It's a real
shame that the documentation on this stops around 5 years ago.

IPA devs: is there anything i should be on the lookout for in the dirsrv
or krb5 logs on the IPA master?  I've disabled the secondary to prevent
replication from clouding the log events

thanks, everyone

Cal Sawyer | Systems Engineer | BlueBolt Ltd
15-16 Margaret Street | London W1W 8RW+44 (0)20 7637 5575 | 
www.blue-bolt.com

On 21/12/15 07:57, Nicola Canepa wrote:

Hello, I tried 2 weeks ago from Mavericks (OSX 10.9), but I had the
opposite problem: kinit works fine, while I'm unable to see users with
Directory Admin ((it always says it cant' connect, either 

[Freeipa-users] FreeIPA+FreeRadius+OpenVPN

[Ciociu Calin]

Hello everyone,

I recently started using FreeIPA and FreeRadius so I might still have some 
misconceptions.

What I am trying to achieve is to have clients use client certificate to login 
into OpenVPN using FreeRadius and FreeIPA.
So far clients can connect to OpenVPN (radiusplugin) with FreeRadius (through 
kerberos) through FreeIPA using username+password login which works as intended.

My question now is how would I go about creating client certificates in FreeIPA 
(created through the web gui for example) which clients can use to login into 
OpenVPN.
I don’t want them to login with username+password but rather with certificates 
which are managed by FreeIPA.

I was looking into EAP-TLS but I am not sure I am on the right path.

OpenVPN is on a separate server running Debian 8

FreeRadius and FreeIPA are both running on another Debian 8 machine. (they are 
both on the same machine though)


Is this possible and if so how would I have to configure the services, or am I 
doing things more complicated than actually needed?


Sincerely yours,
Calin

-- 
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] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

[Dan.Finkelstein]

Solution found (or, if not, a workaround):
IPA replicas must be named in the root domain/zone and not in a subdomain, else 
DNS fails to serve records in the root domain. Once we changed our 
configuration to reflect this, DNS returned to normal.

—Dan

[cid:image001.jpg@01D1CB9B.D6819140]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007
www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.

From:  on behalf of Daniel Finkestein 

Date: Tuesday, June 21, 2016 at 07:21
To: "freeipa-users@redhat.com" 
Subject: Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the 
top-level domain/zone

Hi Petr,

Top level means the root zone of the various DNS trees we serve. For example, 
h5g.com would be the root and dev.h5g.com, test.h5g.com, etc., would be the 
subdomains. Our subdomains query fine, but any hosts in the root domain no 
longer resolve.

An example of an unresolvable name is IPA itself: ipa.h5g.com. Here's output 
from dig:

root@ipa ~]# dig ipa.h5g.com

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> ipa.h5g.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52405
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipa.h5g.com.  INA

;; Query time: 0 msec
;; SERVER: 10.55.10.31#53(10.55.10.31)
;; WHEN: Tue Jun 21 07:15:14 EDT 2016
;; MSG SIZE  rcvd: 42

We expect that its IP address returns from dig, but it doesn't.

We have 100 zones defined, including forward and reverse zones — all active.

We do use DNS forwarding, but in a very unsophisticated way: we set up the 
forwarders to go to Google if our DNS can't resolve a name.

Thanks and regards,
Dan

[cid:image002.jpg@01D1CB9B.D6819140]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007
www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.

From:  on behalf of Petr Spacek 

Organization: Red Hat
Date: Tuesday, June 21, 2016 at 06:04
To: "freeipa-users@redhat.com" 
Subject: Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the 
top-level domain/zone

On 21.6.2016 11:23, 
dan.finkelst...@high5games.com wrote:
We've recently set up a "clean" install of FreeIPA replete with replicas, but 
we just noticed an odd behavior in the DNS service: hosts in the top level 
domain (like ipa.example.com) do not resolve, whereas hosts in subdomains (like 
ipa.dev.example.com) do. I'm not sure what to look for in the various log files 
but I don't see any obvious errors. I thought perhaps this might have some 
guidance https://www.redhat.com/archives/freeipa-users/2015-July/msg00102.html, 
and maybe it does, but I'm not sure how to rescue my top-level domain names.

Hi,

we can certainly debug this but first of all, please clarify what 'top-level'
means.

If you really want help please do not obfuscate any DNS names. It often hides
real problems while not 

[Freeipa-users] AD trust with POSIX attributes

[Jan Karásek]

Hi all, 

I have a questions about IPA with AD forest trust. What I am trying to do is 
setup environment, where all informations about users are stored in one place - 
AD. I would like to read at least uid, home, shell and sshkey from AD. 

I have set up trust with this parameters: 

ipa trust-add EXAMPLE.TT --type=ad --range-type=ipa-ad-trust-posix 
--admin=administrator 

[root@ipa1 ~]# ipa idrange-show EXAMPLE.TT_id_range 
Range name: EXAMPLE.TT_id_range 
First Posix ID of the range: 139200 
Number of IDs in the range: 20 
Domain SID of the trusted domain: S-1-5-21-4123312533-990676102-3576722756 
Range type: Active Directory trust range with POSIX attributes 


I have set attributes in AD for u...@example.tt 
- uidNumber -1 
- homeDirectory -/home/user 
- loginShell - /bin/bash 

Trust itself works fine. I can do kinit with u...@example.tt , I can run id and 
getent passwd u...@example.tt and I can use u...@example.tt for ssh. 

Problem is, that I am not getting uid from AD but from idrange: 

uid=1392001107(u...@example.tt) 

Also I have tried to switch off id mapping in sssd.conf with ldap_id_mapping = 
true in sssd.conf but no luck. 

I know, that it is probably better to use ID views for this, but in our case we 
need to set centrally managed environment, where all users information are 
externally inserted to AD from HR system - included POSIX attributes and we 
need IPA to read them from AD. 

So my questions are: 

Is it possible to read user's POSIX attributes directly from AD - namely uid ? 
Which atributes can be stored in AD ? 
Am I doing something wrong ? 

my sssd.conf: 
[domain/a.example.tt] 
debug_level = 5 
cache_credentials = True 
krb5_store_password_if_offline = True 
ipa_domain = a.example.tt 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = ipa1.a.example.tt 
chpass_provider = ipa 
ipa_server = ipa1.a.example.tt 
ipa_server_mode = True 
ldap_tls_cacert = /etc/ipa/ca.crt 
#ldap_id_mapping = true 
#subdomain_inherit = ldap_user_principal 
#ldap_user_principal = nosuchattribute 

[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 

domains = a.example.tt 
[nss] 
debug_level = 5 
homedir_substring = /home 
enum_cache_timeout = 2 
entry_negative_timeout = 2 


[pam] 
debug_level = 5 
[sudo] 

[autofs] 

[ssh] 
debug_level = 4 
[pac] 

debug_level = 4 
[ifp] 

Thanks, 
Jan 
-- 
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] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Martin Štefany]

On 6/21/2016 1:16 PM, Sumit Bose wrote:

On Tue, Jun 21, 2016 at 12:43:23PM +0200, Martin Štefany wrote:

Hello Sumit,

putting SELinux to permissive mode and/or enabling nis_enabled seboolean
seemed not help at all. And you are right, my user has userCertificate
(needed for secure libvirtd connection).


[martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin@desk2 ~]$ sudo setenforce 0
[sudo] password for martin:
[martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin@desk2 ~]$ sudo setsebool nis_enabled on
[martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin@desk2 ~]$ sudo sss_cache -E
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys

[have a coffee... really]

[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
ssh-rsa AAA...
ssh-rsa AAA...
ssh-ed25519 AAA...
ssh-rsa AAA...
ssh-rsa AAA...


If I understand it correctly you get the same result as on CentOS,
including the unexpected key derived from the certificate, after waiting
for some time? Can you send the sssd_ssh.log with the sequence from
above (if you prefer directly to me) so that I can check why it failed
in the first attempt and later succeeds.

bye,
Sumit



Hi,

yes, now the results are the same, including the originally unexpected 
key from certificate, and actual SSH pubkey auth finally works.


I would send you sssd_ssh.log, but it's empty - I have turned off 
debug_level sooner, sorry. :(


Isn't it the case that sss_cache -E takes few seconds to actually expire 
the cache entries?


Thank you.
Martin




RH bug for selinux-policy:
https://bugzilla.redhat.com/show_bug.cgi?id=1348447

Thank you!
Martin


On 6/21/2016 9:43 AM, Sumit Bose wrote:

On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:

Hello all,

I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) systems
while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same IPA
domain. I will appreciate any help whatsoever.
IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with latest
updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
updates.

I started by looking to the journal:
jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
...
jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { name_connect
} for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e syscall=42
success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0


Does the user by chance have a certificate added to his entry including
a link to an OCSP responder?

Recent version of SSSD have the ability to generate public ssh-keys from
valid certificates added to the user entry to support the ssh Smartcard
feature (see e.g. the -I option in the ssh man page for details or
https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)

While trying to validate thecertificate via OCSP sssd_ssh must connect
to a http server. To allow this setting the 'nis_enabled' SELinux
boolean to true should help.

Nevertheless, since this should work by default, it would be nice if you
can open a bugzilla ticket for the SELinux policy on F23 to allow this
by default.

HTH

bye,
Sumit


...
jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { name_connect
} for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e syscall=42
success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
/usr/bin/sss_ssh_authorizedkeys martin failed, status 1
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Failed publickey for martin
from 144.xxx.xxx.xxx port 22543 ssh2: RSA SHA256:uyzB4[stripped]
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: Received disconnect
from 144.xxx.xxx.xxx port 22543:14: No supported authentication methods
available [preauth]
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Disconnected from 144.xxx.xxx.xxx
port 22543 [preauth]

which was weird, because the same key would nicely work elsewhere (on any other
CentOS 7.2 system, while no Fedora 23 system would work as I have figured out)

I have tried putting SELinux into permissive mode, or generating custom module
with custom policy allowing this, but it doesn't help, and even 

Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

[Dan.Finkelstein]

Hi Petr,

Top level means the root zone of the various DNS trees we serve. For example, 
h5g.com would be the root and dev.h5g.com, test.h5g.com, etc., would be the 
subdomains. Our subdomains query fine, but any hosts in the root domain no 
longer resolve.

An example of an unresolvable name is IPA itself: ipa.h5g.com. Here's output 
from dig:

root@ipa ~]# dig ipa.h5g.com

; <<>> DiG 9.9.4-RedHat-9.9.4-29.el7_2.3 <<>> ipa.h5g.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52405
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ipa.h5g.com.  INA

;; Query time: 0 msec
;; SERVER: 10.55.10.31#53(10.55.10.31)
;; WHEN: Tue Jun 21 07:15:14 EDT 2016
;; MSG SIZE  rcvd: 42

We expect that its IP address returns from dig, but it doesn't.

We have 100 zones defined, including forward and reverse zones — all active.

We do use DNS forwarding, but in a very unsophisticated way: we set up the 
forwarders to go to Google if our DNS can't resolve a name.

Thanks and regards,
Dan

[cid:image001.jpg@01D1CB8D.8C7ACB60]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007
www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.

From:  on behalf of Petr Spacek 

Organization: Red Hat
Date: Tuesday, June 21, 2016 at 06:04
To: "freeipa-users@redhat.com" 
Subject: Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the 
top-level domain/zone

On 21.6.2016 11:23, 
dan.finkelst...@high5games.com wrote:
We've recently set up a "clean" install of FreeIPA replete with replicas, but 
we just noticed an odd behavior in the DNS service: hosts in the top level 
domain (like ipa.example.com) do not resolve, whereas hosts in subdomains (like 
ipa.dev.example.com) do. I'm not sure what to look for in the various log files 
but I don't see any obvious errors. I thought perhaps this might have some 
guidance https://www.redhat.com/archives/freeipa-users/2015-July/msg00102.html, 
and maybe it does, but I'm not sure how to rescue my top-level domain names.

Hi,

we can certainly debug this but first of all, please clarify what 'top-level'
means.

If you really want help please do not obfuscate any DNS names. It often hides
real problems while not improving security in any way. (BTW you do not need to
hide domain names like 'NY5-EXMB1.High5.local' because these already leaked
through e-mail headers :-)

So, here are the important questions:
0) What name is unresolvable?
$ dig the.problematic.name.example.

1) What is the expected result from "dig"?

2) What DNS zones are configured in IPA?
$ ipa dnszone-find

3) Do you use DNS forwarding? (--forwarders option during IPA install or
commands ipa dnsforwardzone-*, ipa dnsconfig-mod etc.)

--
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] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Tue, Jun 21, 2016 at 12:43:23PM +0200, Martin Štefany wrote:
> Hello Sumit,
> 
> putting SELinux to permissive mode and/or enabling nis_enabled seboolean
> seemed not help at all. And you are right, my user has userCertificate
> (needed for secure libvirtd connection).
> 
> 
> [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> Error looking up public keys
> [martin@desk2 ~]$ sudo setenforce 0
> [sudo] password for martin:
> [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> Error looking up public keys
> [martin@desk2 ~]$ sudo setsebool nis_enabled on
> [martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
> Error looking up public keys
> [martin@desk2 ~]$ sudo sss_cache -E
> [martin@desk2 ~]$ sss_ssh_authorizedkeys martin
> Error looking up public keys
> 
> [have a coffee... really]
> 
> [martin@desk2 ~]$ sss_ssh_authorizedkeys martin
> ssh-rsa AAA...
> ssh-rsa AAA...
> ssh-ed25519 AAA...
> ssh-rsa AAA...
> ssh-rsa AAA...

If I understand it correctly you get the same result as on CentOS,
including the unexpected key derived from the certificate, after waiting
for some time? Can you send the sssd_ssh.log with the sequence from
above (if you prefer directly to me) so that I can check why it failed
in the first attempt and later succeeds.

bye,
Sumit

> 
> 
> RH bug for selinux-policy:
> https://bugzilla.redhat.com/show_bug.cgi?id=1348447
> 
> Thank you!
> Martin
> 
> 
> On 6/21/2016 9:43 AM, Sumit Bose wrote:
> > On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:
> > > Hello all,
> > > 
> > > I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
> > > figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) 
> > > systems
> > > while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same 
> > > IPA
> > > domain. I will appreciate any help whatsoever.
> > > IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with 
> > > latest
> > > updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
> > > updates.
> > > 
> > > I started by looking to the journal:
> > > jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
> > > from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> > > name_connect
> > > } for  pid=23328 comm="sssd_ssh" dest=80 
> > > scontext=system_u:system_r:sssd_t:s0
> > > tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> > > syscall=42
> > > success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
> > > ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 
> > > egid=0
> > > sgid=0
> > 
> > Does the user by chance have a certificate added to his entry including
> > a link to an OCSP responder?
> > 
> > Recent version of SSSD have the ability to generate public ssh-keys from
> > valid certificates added to the user entry to support the ssh Smartcard
> > feature (see e.g. the -I option in the ssh man page for details or
> > https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)
> > 
> > While trying to validate thecertificate via OCSP sssd_ssh must connect
> > to a http server. To allow this setting the 'nis_enabled' SELinux
> > boolean to true should help.
> > 
> > Nevertheless, since this should work by default, it would be nice if you
> > can open a bugzilla ticket for the SELinux policy on F23 to allow this
> > by default.
> > 
> > HTH
> > 
> > bye,
> > Sumit
> > 
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> > > name_connect
> > > } for  pid=23328 comm="sssd_ssh" dest=80 
> > > scontext=system_u:system_r:sssd_t:s0
> > > tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> > > jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> > > syscall=42
> > > success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
> > > ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 
> > > egid=0
> > > sgid=0
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
> > > /usr/bin/sss_ssh_authorizedkeys martin failed, status 1
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Failed publickey for martin
> > > from 144.xxx.xxx.xxx port 22543 ssh2: RSA SHA256:uyzB4[stripped]
> > > ...
> > > jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: Received disconnect
> > > from 144.xxx.xxx.xxx port 22543:14: No supported authentication methods
> > > available [preauth]
> > > jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Disconnected from 
> > > 144.xxx.xxx.xxx
> > > port 22543 [preauth]
> > > 
> > > which was weird, because the same key would nicely work elsewhere (on any 
> > > other
> > > CentOS 7.2 system, while no Fedora 23 system would work as I have figured 
> > > out)
> > > 
> > > I have 

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Martin Štefany]

Hello Sumit,

putting SELinux to permissive mode and/or enabling nis_enabled seboolean 
seemed not help at all. And you are right, my user has userCertificate 
(needed for secure libvirtd connection).



[martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin@desk2 ~]$ sudo setenforce 0
[sudo] password for martin:
[martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin@desk2 ~]$ sudo setsebool nis_enabled on
[martin@desk2 ~]$ sss_ssh_authorizedkeys  martin
Error looking up public keys
[martin@desk2 ~]$ sudo sss_cache -E
[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
Error looking up public keys

[have a coffee... really]

[martin@desk2 ~]$ sss_ssh_authorizedkeys martin
ssh-rsa AAA...
ssh-rsa AAA...
ssh-ed25519 AAA...
ssh-rsa AAA...
ssh-rsa AAA...


RH bug for selinux-policy:
https://bugzilla.redhat.com/show_bug.cgi?id=1348447

Thank you!
Martin


On 6/21/2016 9:43 AM, Sumit Bose wrote:

On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:

Hello all,

I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) systems
while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same IPA
domain. I will appreciate any help whatsoever.
IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with latest
updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
updates.

I started by looking to the journal:
jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
...
jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { name_connect
} for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e syscall=42
success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0


Does the user by chance have a certificate added to his entry including
a link to an OCSP responder?

Recent version of SSSD have the ability to generate public ssh-keys from
valid certificates added to the user entry to support the ssh Smartcard
feature (see e.g. the -I option in the ssh man page for details or
https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)

While trying to validate thecertificate via OCSP sssd_ssh must connect
to a http server. To allow this setting the 'nis_enabled' SELinux
boolean to true should help.

Nevertheless, since this should work by default, it would be nice if you
can open a bugzilla ticket for the SELinux policy on F23 to allow this
by default.

HTH

bye,
Sumit


...
jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { name_connect
} for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e syscall=42
success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
/usr/bin/sss_ssh_authorizedkeys martin failed, status 1
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Failed publickey for martin
from 144.xxx.xxx.xxx port 22543 ssh2: RSA SHA256:uyzB4[stripped]
...
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: Received disconnect
from 144.xxx.xxx.xxx port 22543:14: No supported authentication methods
available [preauth]
jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Disconnected from 144.xxx.xxx.xxx
port 22543 [preauth]

which was weird, because the same key would nicely work elsewhere (on any other
CentOS 7.2 system, while no Fedora 23 system would work as I have figured out)

I have tried putting SELinux into permissive mode, or generating custom module
with custom policy allowing this, but it doesn't help, and even tcpdump capture
doesn't capture anything when such connection to 'somewhere' port 80 is opened.

I moved on to testing the '/usr/bin/sss_ssh_authorizedkeys martin' command.
Fedora 23:
# sss_ssh_authorizedkeys martin
Error looking up public keys

CentOS 7.2:
# sss_ssh_authorizedkeys martin
ssh-rsa AAA...
ssh-rsa AAA...
ssh-ed25519 AAA...
ssh-rsa AAA...
ssh-rsa B3NzaC1yc2EDAQABAAABAQCsox... (???) -->> this is one is not in
LDAP (checked with ldapsearch & ipa user-show martin --all --raw), not present
in dc=stefany,dc=eu tree or in compat tree

So, I have turned on debug_level = 0x0250 in sssd.conf in both Fedora 23 and
CentOS 7.2 and checked the logs. CentOS 7.2 is just fine, Fedora 23 gives these
failures:
==> /var/log/sssd/sssd_ssh.log <==
(Mon Jun 20 21:58:14 2016) [sssd[ssh]] 

Re: [Freeipa-users] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

[Petr Spacek]

On 21.6.2016 11:23, dan.finkelst...@high5games.com wrote:
> We've recently set up a "clean" install of FreeIPA replete with replicas, but 
> we just noticed an odd behavior in the DNS service: hosts in the top level 
> domain (like ipa.example.com) do not resolve, whereas hosts in subdomains 
> (like ipa.dev.example.com) do. I'm not sure what to look for in the various 
> log files but I don't see any obvious errors. I thought perhaps this might 
> have some guidance 
> https://www.redhat.com/archives/freeipa-users/2015-July/msg00102.html, and 
> maybe it does, but I'm not sure how to rescue my top-level domain names.

Hi,

we can certainly debug this but first of all, please clarify what 'top-level'
means.

If you really want help please do not obfuscate any DNS names. It often hides
real problems while not improving security in any way. (BTW you do not need to
hide domain names like 'NY5-EXMB1.High5.local' because these already leaked
through e-mail headers :-)

So, here are the important questions:
0) What name is unresolvable?
$ dig the.problematic.name.example.

1) What is the expected result from "dig"?

2) What DNS zones are configured in IPA?
$ ipa dnszone-find

3) Do you use DNS forwarding? (--forwarders option during IPA install or
commands ipa dnsforwardzone-*, ipa dnsconfig-mod etc.)

-- 
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] CentOS 6.8: uninstalling IPA client causes python error

[Dan.Finkelstein]

Oh, I disabled that first. I turn on services and restrictions one-by-one after 
things are working, not before.
—Dan

[cid:image001.jpg@01D1CB7D.8BC9E530]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007
www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.

From: Rob Crittenden 
Date: Saturday, June 18, 2016 at 23:00
To: Daniel Finkestein , 
"freeipa-users@redhat.com" 
Subject: Re: [Freeipa-users] CentOS 6.8: uninstalling IPA client causes python 
error

I'd check for SELinux errors, that might explain things.

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] CentOS 7 & FreeIPA 4.2: DNS resolution at the top-level domain/zone

[Dan.Finkelstein]

We've recently set up a "clean" install of FreeIPA replete with replicas, but 
we just noticed an odd behavior in the DNS service: hosts in the top level 
domain (like ipa.example.com) do not resolve, whereas hosts in subdomains (like 
ipa.dev.example.com) do. I'm not sure what to look for in the various log files 
but I don't see any obvious errors. I thought perhaps this might have some 
guidance https://www.redhat.com/archives/freeipa-users/2015-July/msg00102.html, 
and maybe it does, but I'm not sure how to rescue my top-level domain names.

Thanks and regards,
Dan

[cid:image001.jpg@01D1CB7D.143197C0]
Daniel Alex Finkelstein| Lead Dev Ops Engineer
dan.finkelst...@h5g.com | 212.604.3447
One World Trade Center, New York, NY 10007
www.high5games.com
Play High 5 Casino and Shake the 
Sky
Follow us on: Facebook, 
Twitter, 
YouTube, 
Linkedin

This message and any attachments may contain confidential or privileged 
information and are only for the use of the intended recipient of this message. 
If you are not the intended recipient, please notify the sender by return 
email, and delete or destroy this and all copies of this message and all 
attachments. Any unauthorized disclosure, use, distribution, or reproduction of 
this message or any attachments is prohibited and may be unlawful.
-- 
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] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Mon, Jun 20, 2016 at 10:46:13PM +0200, Martin Štefany wrote:
> Hello all,
> 
> I've ran into strange issue with IPA/SSSD/SSH/SELinux which started when I
> figured out that I cannot ssh with pubkey auth to Fedora 23 (ipa-client) 
> systems
> while I can to CentOS 7.2 (ipa-client and ipa-server) systems within same IPA
> domain. I will appreciate any help whatsoever.
> IPA servers (and most of the clients) are IPA 4.2.0 on CentOS 7.2 with latest
> updates, affected clients are IPA clients 4.2.4 on Fedora 23 with latest
> updates.
> 
> I started by looking to the journal:
> jún 20 13:02:50 desk2.stefany.eu sshd[25162]: Connection
> from 144.xxx.xxx.xxx port 22543 on 172.17.100.191 port 22
> ...
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> name_connect
> } for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
> tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> syscall=42
> success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe2a50 items=0
> ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 

Does the user by chance have a certificate added to his entry including
a link to an OCSP responder?

Recent version of SSSD have the ability to generate public ssh-keys from
valid certificates added to the user entry to support the ssh Smartcard
feature (see e.g. the -I option in the ssh man page for details or
https://fedorahosted.org/sssd/wiki/DesignDocs/SmartcardAuthenticationStep1#RunningsshclientwithSmartcardsupport)

While trying to validate thecertificate via OCSP sssd_ssh must connect
to a http server. To allow this setting the 'nis_enabled' SELinux
boolean to true should help.

Nevertheless, since this should work by default, it would be nice if you
can open a bugzilla ticket for the SELinux policy on F23 to allow this
by default.

HTH

bye,
Sumit

> ...
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: AVC avc:  denied  { 
> name_connect
> } for  pid=23328 comm="sssd_ssh" dest=80 scontext=system_u:system_r:sssd_t:s0
> tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
> jún 20 13:02:56 desk2.stefany.eu audit[23328]: SYSCALL arch=c03e 
> syscall=42
> success=no exit=-13 a0=15 a1=7fff145c35b0 a2=10 a3=5614dbbe42d0 items=0
> ppid=23316 pid=23328 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 
> ...
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: AuthorizedKeysCommand
> /usr/bin/sss_ssh_authorizedkeys martin failed, status 1
> ...
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Failed publickey for martin
> from 144.xxx.xxx.xxx port 22543 ssh2: RSA SHA256:uyzB4[stripped]
> ...
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: error: Received disconnect
> from 144.xxx.xxx.xxx port 22543:14: No supported authentication methods
> available [preauth]
> jún 20 13:02:56 desk2.stefany.eu sshd[25162]: Disconnected from 
> 144.xxx.xxx.xxx
> port 22543 [preauth]
> 
> which was weird, because the same key would nicely work elsewhere (on any 
> other
> CentOS 7.2 system, while no Fedora 23 system would work as I have figured out)
> 
> I have tried putting SELinux into permissive mode, or generating custom module
> with custom policy allowing this, but it doesn't help, and even tcpdump 
> capture
> doesn't capture anything when such connection to 'somewhere' port 80 is 
> opened.
> 
> I moved on to testing the '/usr/bin/sss_ssh_authorizedkeys martin' command.
> Fedora 23:
> # sss_ssh_authorizedkeys martin
> Error looking up public keys
> 
> CentOS 7.2:
> # sss_ssh_authorizedkeys martin
> ssh-rsa AAA...
> ssh-rsa AAA...
> ssh-ed25519 AAA...
> ssh-rsa AAA...
> ssh-rsa B3NzaC1yc2EDAQABAAABAQCsox... (???) -->> this is one is not in
> LDAP (checked with ldapsearch & ipa user-show martin --all --raw), not present
> in dc=stefany,dc=eu tree or in compat tree
> 
> So, I have turned on debug_level = 0x0250 in sssd.conf in both Fedora 23 and
> CentOS 7.2 and checked the logs. CentOS 7.2 is just fine, Fedora 23 gives 
> these
> failures:
> ==> /var/log/sssd/sssd_ssh.log <==
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): 
> Received
> client version [0].
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): Offered
> version [0].
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [sss_parse_name_for_domains] (0x0200):
> name 'martin' matched without domain, user is martin
> 
> ==> /var/log/sssd/sssd_stefany.eu.log <==
> (Mon Jun 20 21:58:14 2016) [sssd[be[stefany.eu]]] [be_get_account_info]
> (0x0200): Got request for [0x1][BE_REQ_USER][1][name=martin]
> 
> ==> /var/log/sssd/sssd_ssh.log <==
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
> cert_to_ssh_key failed.
> (Mon Jun 20 21:58:14 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040):
> decode_and_add_base64_data failed.
> 
> And that's right, the last - ghost - "sshpubkey" is 

Re: [Freeipa-users] Active Directory password sync fails with RC 34

[Toby Gale]

Thanks for the help Rich.

Looking at the log I noticed some extra characters in the DN that
corresponds to "Search Base".  I got the Windows admin to share his RDP
session to the DC and had a look at the registry in
"HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync".
I noticed the same characters in the "Search Base" key.  I think the extra
characters were accidentally copy-pasted from the documentation I sent them.

Removing them and restarting the service has resolved the problem.


On Mon, Jun 20, 2016 at 3:49 PM, Rich Megginson  wrote:

> On 06/18/2016 05:47 AM, Toby Gale wrote:
>
> Hello,
>
> After successfully adding a 'winsync' agreement and loading AD data into
> FreeIPA I am trying to configure the password sync software on the domain
> controllers.
>
> I have installed the certificates and can successfully bind from the
> domain controller using ldp.exe and the
> 'uid=passsync,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com' user.
>
> I have edited the registry to increase logging, by setting
> 'HKEY_LOCAL_MACHINE\SOFTWARE\PasswordSync\Log Level' to '1' and I am seeing
> the error:
>
> 06/17/16 08:47:32: Backoff time expired.  Attempting sync
> 06/17/16 08:47:32: Password list has 1 entries
> 06/17/16 08:47:32: Attempting to sync password for some.user
> 06/17/16 08:47:32: Searching for (ntuserdomainid=some.user)
> 06/17/16 08:47:32: Ldap error in QueryUsername
> 34: Invalid DN syntax
>
>
> Take a look at the 389/dirsrv access log on your linux host at
> /var/log/dirsrv/slapd-HOSTNAME/access - see if you can find the error
> corresponding to this - it should be at the same approximate date/time
> (make sure you check your time zones) and the RESULT line should have err=34
>
> 06/17/16 08:47:32: Deferring password change for some.user
> 06/17/16 08:47:32: Backing off for 1024000ms
>
> When I run the query from the CLI, it is successful:
>
> $ ldapsearch -x -h ldaps://localhost -p 636 -D
> 'uid=passsync,cn=sysaccounts,cn=etc,dc=dc,my=domain,dc=com' -w 'password'
>  -b 'cn=users,cn=accounts,dc=my,dc=domain,dc=com'
> '(ntuserdomainid=some.user)'
>
> Can anyone help me resolve this?
>
> Thanks.
>
>
>
>
> --
> 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