Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

I think the thing that frustrates the most is that id u...@domain.com is
returning correct data on both but they can't loginand I can't even
show that this is the case because now they can login. Difficult to
reproduce :/

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

- Grace Hopper

On 19 July 2016 at 11:13, Lachlan Musicman  wrote:

> Ok, the bad news is that it didn't last. We are still having the same
> problem - HBAC is rejecting users because not all jobs are being discovered
> on the host.
>
> I turned the debug_level up to 10 as requested, but to be honest, it's
> impossible to find anything in the logs because it's so verbose - suddenly
> there are timer events everywhere. I'm going to turn it down to 7 again so
> I can actually parse it.
>
> Cheers
> L.
>
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
>
> - Grace Hopper
>
> On 15 July 2016 at 17:56, Jakub Hrozek  wrote:
>
>> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
>> > I've updated all the relevant hosts and the FreeIPA server to the COPR
>> sssd
>> > 1.14.0 release and the problem seems to have disappeared.
>>
>> Great, but please keep an eye on the machine, the 1.14 branch is still
>> kindof fresh and we did a lot of changes.
>>
>> About the HBAC issue, did you use the default_domain_suffix previously?
>>
>> --
>> Manage your subscription for the Freeipa-users mailing list:
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>> Go to http://freeipa.org for more info on the project
>>
>
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] HBAC and AD users

[Lachlan Musicman]

Ok, the bad news is that it didn't last. We are still having the same
problem - HBAC is rejecting users because not all jobs are being discovered
on the host.

I turned the debug_level up to 10 as requested, but to be honest, it's
impossible to find anything in the logs because it's so verbose - suddenly
there are timer events everywhere. I'm going to turn it down to 7 again so
I can actually parse it.

Cheers
L.

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

- Grace Hopper

On 15 July 2016 at 17:56, Jakub Hrozek  wrote:

> On Fri, Jul 15, 2016 at 01:07:00PM +1000, Lachlan Musicman wrote:
> > I've updated all the relevant hosts and the FreeIPA server to the COPR
> sssd
> > 1.14.0 release and the problem seems to have disappeared.
>
> Great, but please keep an eye on the machine, the 1.14 branch is still
> kindof fresh and we did a lot of changes.
>
> About the HBAC issue, did you use the default_domain_suffix previously?
>
> --
> 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] Unable to ssh after establishing trust

[pgb205]

Sumit,
I have set the names of all the Domain Controllers to be resolvable to the IP 
of the one reachable Domain Controller in /etc/hosts
/etc/hosts:Reachable_IP_BOX   172.10.10.1DC1                            
172.10.10.1DC2                            172.10.10.1..
However, I still see the followingMarking SRV lookup of service 
'gc_addomain.local' as 'neutral'
Marking server dc1.addomain.local' as 'name not resolved'

Additionally I have configured [domain/ipa.internal]
      with 
subdomain_inherit = ldap_user_principalldap_user_principal = nosuchattr

As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be 
the old hostname of the IPA KDC.After much troubleshooting I believe I got this 
fixed by deleting  extra folders in
/var/named/dyndb-ldap/ipa/masterRight now the only two folders are ipa.internal 
and .in-addr.arpa.
I think this is what helped with this issue. but can you please confirm if it 
sounds reasonable.

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

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

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

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

    dig SRV _ldap._tcp.ad_domain.local

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

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

bye,
Sumit

> 
>      From: Sumit Bose 
>  To: pgb205  
> Cc: Sumit Bose 
>  Sent: Tuesday, July 12, 2016 5:37 AM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>  
> On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > Sumit, 
> > sssd log files attached with debug=10 in all sections.I have attempted 
> > several logins for comparison as well as kinit commands
> 
> I came across two issues in the logs.
> 
> First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
> AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
> FreeIPA cannot resolve those principals correctly. It was planned for
> IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
> be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
> please try to work-around suggested at the end of
> http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
> authenticate with user@AD_DOMAIN.COM SSSD looks for a server called
> ewr-fipa_server.ad_domain.com but cannot find it an return the error code
> for "Cannot contact any KDC for requested realm".
> 
> Second there are some issues access AD DCs via LDAP. SSSD tries to
> connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but
> both fails. It is not clear from the logs if already the DNS lookup for
> those fails or if the connection itself runs into a timeout. In the
> former case you should make 

Re: [Freeipa-users] non-authoritative tricks for DNS resolution

[Brendan Kearney]

On 07/18/2016 06:12 AM, Petr Spacek wrote:

On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote:

Would a DNS view (bind) work?

http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm

Also, depending on what you are using for NAT, some devices will mangle the 
reply payload of A record lookups as they traverse NAT to avoid haripinning (a 
packet going out and then back in the same interface as it traverses NAT).  
This is known as DNS doctoring, at least in the world of Cisco.

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html

Let me know if either of those will solve your problem.  If not, I might have a 
misunderstanding of what you are asking.

Dan


On Jul 17, 2016, at 3:36 PM, Brendan Kearney  wrote:

i am looking to setup a VPN in order to access some resources, and want to 
point my clients at this resource via DNS.  the resource i am accessing is 
internet resolvable, but i am accessing it via the VPN, and using a NAT for the 
VPN (full 1-to-1 or static NAT).  i want to have a record in my DNS for this 
resource, using its proper name (which i am not authoritative for), but assign 
it the IP of my NAT.

say for example, host.domain-ext.tld is the resource i want to access, and it 
resolves externally to 1.2.3.4.  my VPN NAT would be 192.168.99.137.  i want 
internal resolution of DNS to point to 192.168.99.137 so the network routing 
takes my internal clients to the VPN and not out to the internet.

i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for dns.  how do i 
setup the zone and record to accomplish this DNS trick?  i have talked with some DNS 
gurus and they indicate that i can do something with the "@" record.  it seems 
that the record i want, would be its own zone, and the @ record would point to the name, 
and the SOA would be the NAT IP.  i could be wrong about the details, but something like 
this is how to setup resolution the way i want.

any pointers would be greatly appreciated.

Background note:
All these DNS tricks are hacks to work around IP routing problem in
configuration you described.

If you really want to use DNS tricks, you can create a DNS zone with name
equal to the you want to override and will this zone with A/ record at
zone apex (@).
The DNS approach has some inherent advantages:

1. All DNS names below the name you want to 'hijack' will not be resolvable in
your network. E.g. if the name is hijacked.example.com. then sub-domains like
anything.hijacked.example.com. will not be resolvable.

2. Your clients will go securely over VPN if and only if they use your local
DNS servers. Any client configured (even accidentally) to use some other DNS
server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel
the traffic over VPN.


Secure and reliable solution is not to use DNS but solve things on IP layer:
On the network gateway, configure IPSec tunnel (or any other VPN) in a way
that *the original IP address* is routed over VPN.

This does not require any DNS tricks and thus will work regardless of client
configuration.

I hope it helps.

our posture states that we do not route network space that is not ours, 
unless exigent circumstances dictate otherwise.  we have dedicated 
address space to NAT pools, in order to facilitate this. we also forbid 
external dns resolution from endpoints, by limiting what can go out to 
the roots for recursion.  misconfigured clients are not able to perform 
DNS resolution.  we work with our counterparts on the other side of the 
VPN to ensure we are only adding a host record, and that sub-domains are 
not a point of failure for our access.


in terms of setting up this zone, how would one construct the ldif to 
create it?  because i am not using FreeIPA, i do not have the seemingly 
built-in tools to perform this function.  any reading material on the 
subject is welcomed.


thanks,

brendan

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

[Kai Engert]

On Mon, 2016-07-18 at 11:42 -0400, Rob Crittenden wrote:
> That I'm not sure. Kai might know.

Since there were several open questions, we discussed that on IRC.

To summarize here: if you want to install a CA that should be trusted by all
applications on a system, you probably shouldn't install into /etc/pki/nssdb any
more.

Instead, you should install to the proper directory below
/etc/pki/ca-trust/source/
and execute update-ca-trust (see the man page).

In addition, if you write an NSS application and you want it to trust (and
distrust) all the CAs that are installed globally on the system, then, after you
init NSS using the usual init APIs, you should execute a call to load the NSS
trust module, which is named libnssckbi.so

The call is 
SECMOD_AddNewModule("Builtins", DLL_PREFIX "nssckbi." DLL_SUFFIX, 0, 0); 

(the DLL_*FIX symbols are helpful when you need cross platform code)

An example is here: https://hg.mozilla.org/projects/nss/file/tip/cmd/tstclnt/tst
clnt.c#l1312

Note that the libnssckbi.so in the LD search path is a symbolic link, which on
modern systems points to the replacement module from p11-kit-trust.rpm, which
will dynamically give you the trust information that's managed as explained in
the update-ca-trust manual page.

Kai

-- 
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] ns-slapd hangs for 2-3 minutes, then resumes.

[Guillermo Fuentes]

Hi all,

Did any ipa/sssd developer had a chance to take a look at this issue?

Updating to the latest version available for CentOS 7 didn't fix it:
ipa-debuginfo-4.2.0-15.0.1.el7_2.6.1.x86_64
ipa-python-4.2.0-15.0.1.el7.centos.17.x86_64
ipa-server-dns-4.2.0-15.0.1.el7.centos.17.x86_64
sssd-ipa-1.13.0-40.el7_2.9.x86_64
python-libipa_hbac-1.13.0-40.el7_2.9.x86_64
ipa-admintools-4.2.0-15.0.1.el7.centos.17.x86_64
ipa-server-4.2.0-15.0.1.el7.centos.17.x86_64
libipa_hbac-1.13.0-40.el7_2.9.x86_64
ipa-server-trust-ad-4.2.0-15.0.1.el7.centos.17.x86_64
ipa-client-4.2.0-15.0.1.el7.centos.17.x86_64

389-ds-base-libs-1.3.4.0-32.el7_2.x86_64
389-ds-base-1.3.4.0-32.el7_2.x86_64
389-ds-base-debuginfo-1.3.4.0-30.el7_2.x86_64


Please let me know if you need more information or how I can help to get it
fixed.

Thanks so much,
Guillermo


On Mon, Jun 13, 2016 at 6:30 PM, Rich Megginson  wrote:

> On 06/13/2016 01:13 PM, Guillermo Fuentes wrote:
>
>> Hi Rich,
>>
>> After I started running the stack traces, the problem hasn't happen as
>> frequently as it use to but today I was able to get the stack traces.
>> As they aren't similar I'll send them over to you in a separate email.
>>
>> This is what I did to start the stack traces (CentOS 7):
>> # yum install -y --enablerepo=base-debuginfo 389-ds-base-debuginfo
>> ipa-debuginfo slapi-nis-debuginfo nspr-debuginfo
>> # yum install -y gdb
>> # systemctl stop ipa.service ; sleep 10; systemctl start ipa.service
>> # mkdir -p /var/log/stacktraces
>>
>> Setup crontab to run the following every minute:
>> gdb -ex 'set confirm off' -ex 'set pagination off' -ex 'thread apply
>> all bt full' -ex 'quit' /usr/sbin/ns-slapd `pidof ns-slapd` >
>> /var/log/stacktraces/stacktrace.`date +%s`.txt 2>&1
>>
>
> It looks similar to https://fedorahosted.org/389/ticket/48341 but you
> already have that fix.
>
> One of the problems is that ids_sasl_check_bind acquires the connection
> lock and holds it for a very long time, which causes the main loop to block
> on that connection, which is similar to the above problem, and also similar
> to https://fedorahosted.org/389/ticket/48882.  Basically, anything which
> holds the connection c_mutex lock too long can hang the server.  In your
> case, this stack trace:
>
> poll sss_cli_make_request_nochecks sss_cli_check_socket
> sss_pac_make_request sssdpac_verify krb5int_authdata_verify
> rd_req_decoded_opt krb5_rd_req_decoded kg_accept_krb5
> krb5_gss_accept_sec_context_ext krb5_gss_accept_sec_context
> gss_accept_sec_context gssapi_server_mech_step sasl_server_step
> sasl_server_start ids_sasl_check_bind do_bind connection_dispatch_operation
> _pt_root start_thread clone
>
> I'm not sure if this particular situation is known/fixed.  Perhaps there
> is a way to make the poll() called by sss_cli_make_request_nochecks() have
> a smaller timeout?
>
> Does this look familiar to any ipa/sssd developer?
>
>
>
>> Thank you so much for your help,
>>
>> Guillermo
>>
>>
>>
>>
>>
>>
>> On Wed, Jun 1, 2016 at 6:52 PM, Guillermo Fuentes
>>  wrote:
>>
>>> I'm now taking stack traces every minute and waiting for it to hang
>>> again to check it. It happens usually under load but it's
>>> unpredictable. Must likely tomorrow.
>>> GUILLERMO FUENTES
>>> SR. SYSTEMS ADMINISTRATOR
>>>
>>> 561-880-2998 x1337
>>>
>>> guillermo.fuen...@modmed.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 1, 2016 at 2:03 PM, Rich Megginson 
>>> wrote:
>>>
 On 06/01/2016 10:37 AM, Guillermo Fuentes wrote:

> Hi all,
>
> We are experiencing a similar issue like the one discussed in the
> following thread but we are running FreeIPA 4.2 on CentOS 7.2:
>
> https://www.redhat.com/archives/freeipa-users/2015-February/msg00205.html
>

 Are your stack traces similar?


 LDAP service stops responding to queries (hangs). LDAP connections on
> the server climb sometimes up to 10 times the normal amount and load
> goes to 0. Then, the connections start to drop until they get to a
> normal level and the LDAP service starts to respond to queries again.
> This happens in between 3-5 minutes:
>
> Time,LDAP conn, Opened files(ns-slapd), File
> Desc(ns-slapd),Threads(ns-slapd),Load1,Load5,Load15
> 8:54:03,101,353,216,142,0.43,0.20,0.16
> 8:55:02,108,359,221,142,0.19,0.18,0.15
> 8:56:03,110,361,224,142,0.07,0.15,0.14
> 8:57:14,117,383,246,142,0.15,0.16,0.15
> 8:58:04,276,371,234,142,0.05,0.13,0.14
> 8:59:05,469,371,234,142,0.02,0.11,0.13
> 9:00:08,719,371,234,142,0.01,0.09,0.12
> 9:01:18,1060,371,234,142,0.00,0.07,0.12
> 9:02:10,742,371,233,142,0.10,0.09,0.12
> 9:03:06,365,372,235,142,0.13,0.10,0.13
> 9:04:04,262,379,242,142,0.87,0.29,0.19
> 9:05:02,129,371,233,142,0.51,0.31,0.20
> 9:06:03,126,377,240,142,0.42,0.33,0.22
> 9:07:03,125,377,238,142,0.17,0.27,0.21
>
> Nothing is logged in the 

Re: [Freeipa-users] IPA certificates expired, please help!

[Linov Suresh]

*Update: my webserver and LDAP certificates were expired at 2016-07-18
15:54:36 UTC and the certificates are in CA_UNREACHABLE state.*


*Could you please help us? *

[root@caer tmp]# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20111214223243':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed
to execute the HTTP POST transaction.  Peer certificate cannot be
authenticated with known CA certificates).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=caer.teloip.net,O=TELOIP.NET
   * expires: 2016-07-18 15:54:36 UTC*
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20111214223300':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed
to execute the HTTP POST transaction.  Peer certificate cannot be
authenticated with known CA certificates).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=caer.teloip.net,O=TELOIP.NET
   * expires: 2016-07-18 15:54:52 UTC*
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20111214223316':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed
to execute the HTTP POST transaction.  Peer certificate cannot be
authenticated with known CA certificates).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=caer.teloip.net,O=TELOIP.NET
*expires: 2016-07-18 15:55:04 UTC*
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20130519130741':
status: MONITORING
ca-error: Internal error: no response to "
http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=61=true=true
".
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=CA Audit,O=TELOIP.NET
expires: 2017-10-13 14:10:49 UTC
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130519130742':
status: MONITORING
ca-error: Internal error: no response to "
http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=60=true=true
".
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
certificate:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=OCSP Subsystem,O=TELOIP.NET
expires: 2017-10-13 14:09:49 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130519130743':
status: MONITORING
ca-error: Internal error: no response to "
http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=62=true=true
".
stuck: no
key pair storage:
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert
cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
certificate:

Re: [Freeipa-users] IPA certificates expired, please help!

[Linov Suresh]

Yes, PKI is running and I don't see any errors in selftests, I have
followed https://access.redhat.com/solutions/643753 and restarted the PKI
in step 10.

The only change which I made was clean up userCertificate;binary before
adding new userCertificate in LDAP, which is step 12.

[root@caer ~]# /etc/init.d/pki-cad status
pki-ca (pid 8634) is running...[  OK  ]
Unsecure Port   = http://caer.teloip.net:9180/ca/ee/ca
Secure Agent Port   = https://caer.teloip.net:9443/ca/agent/ca
Secure EE Port  = https://caer.teloip.net:9444/ca/ee/ca
Secure Admin Port   = https://caer.teloip.net:9445/ca/services
EE Client Auth Port = https://caer.teloip.net:9446/ca/eeca/ca
PKI Console Port= pkiconsole https://caer.teloip.net:9445/ca
Tomcat Port = 9701 (for shutdown)

PKI Instance Name:   pki-ca

PKI Subsystem Type:  Root CA (Security Domain)

Registered PKI Security Domain Information:

==
Name:  IPA
URL:   https://caer.teloip.net:9445

==
[root@caer ~]#
[root@caer ~]# tail -f /var/log/pki-ca/selftests.log
8634.main - [18/Jul/2016:11:46:20 EDT] [20] [1] SelfTestSubsystem:  loading
all self test plugin logger parameters
8634.main - [18/Jul/2016:11:46:20 EDT] [20] [1] SelfTestSubsystem:  loading
all self test plugin instances
8634.main - [18/Jul/2016:11:46:20 EDT] [20] [1] SelfTestSubsystem:  loading
all self test plugin instance parameters
8634.main - [18/Jul/2016:11:46:20 EDT] [20] [1] SelfTestSubsystem:  loading
self test plugins in on-demand order
8634.main - [18/Jul/2016:11:46:20 EDT] [20] [1] SelfTestSubsystem:  loading
self test plugins in startup order
8634.main - [18/Jul/2016:11:46:20 EDT] [20] [1] SelfTestSubsystem: Self
test plugins have been successfully loaded!
8634.main - [18/Jul/2016:11:46:21 EDT] [20] [1] SelfTestSubsystem: Running
self test plugins specified to be executed at startup:
8634.main - [18/Jul/2016:11:46:21 EDT] [20] [1] CAPresence:  CA is present
8634.main - [18/Jul/2016:11:46:21 EDT] [20] [1] SystemCertsVerification:
system certs verification success
8634.main - [18/Jul/2016:11:46:21 EDT] [20] [1] SelfTestSubsystem: All
CRITICAL self test plugins ran SUCCESSFULLY at startup!

Your help is highly appreciated!


   Linov Suresh

   70 Forest Manor Rd.
   Toronto
   ON M2J 0A9
   Mobile: +1 647 406 9438
   Linkedin: ca.linkedin.com/in/linov/
   Website: http://mylinuxthoughts.blogspot.com


On Mon, Jul 18, 2016 at 10:50 AM, Petr Vobornik  wrote:

> On 07/18/2016 05:45 AM, Linov Suresh wrote:
> > Thanks for the update Rob. I went back to Jan 20, 2016, restarted CA and
> > certmonger. Look like certificates were renewed. But I'm getting a
> different
> > error now,
> >
> > *ca-error: Internal error: no response to
> > "
> http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=62=true=true
> ".*
>
> Is PKI running? When you change the time, does restart of IPA help?
>
> >
> > [root@caer ~]# getcert list
> > Number of certificates and requests being tracked: 8.
> > Request ID '20111214223243':
> >  status: MONITORING
> >  stuck: no
> >  key pair storage:
> >
> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
> > Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
> >  certificate:
> >
> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
> > Certificate DB'
> >  CA: IPA
> >  issuer: CN=Certificate Authority,O=TELOIP.NET <
> http://TELOIP.NET>
> >  subject: CN=caer.teloip.net ,O=
> TELOIP.NET
> > 
> >  expires: 2016-07-18 15:54:36 UTC
> >  eku: id-kp-serverAuth
> >  pre-save command:
> >  post-save command:
> >  track: yes
> >  auto-renew: yes
> > Request ID '20111214223300':
> >  status: MONITORING
> >  stuck: no
> >  key pair storage:
> >
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> Certificate
> > DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
> >  certificate:
> >
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
> Certificate
> > DB'
> >  CA: IPA
> >  issuer: CN=Certificate Authority,O=TELOIP.NET <
> http://TELOIP.NET>
> >  subject: CN=caer.teloip.net ,O=
> TELOIP.NET
> > 
> >  expires: 2016-07-18 15:54:52 UTC
> >  eku: id-kp-serverAuth
> >  pre-save command:
> >  post-save command:
> >  track: yes
> >  auto-renew: yes
> > Request ID '20111214223316':
> >  status: MONITORING
> >  stuck: no
> >  key pair storage:
> > 

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

[Rob Crittenden]

Sumit Bose wrote:

On Mon, Jul 18, 2016 at 09:54:37AM -0400, Rob Crittenden wrote:

Sumit Bose wrote:

On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:

On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:

On (16/07/16 10:19), Martin Štefany wrote:


Hello Sumit,

seems that upgrade to F24 broke things again. This time no AVCs, empty SSSD
logs, but same problem: 'Error looking up public keys'.

selinux-policy-3.13.1-191.fc24.3.noarch
selinux-policy-targeted-3.13.1-191.fc24.3.noarch
sssd-1.13.4-3.fc24.x86_64


Fedora 23 and fedora 24 has the same version of sssd
and almost the same version of openssh.
I have no idea what coudl broke it it there are not any AVCs.



Using debug_level 0x0250 ::


For troubleshooting, it would be better to see all
debug messages. (debug_level = 0xfff0)


Hello Lukas,

thanks for replying on this, here are debug_level = 0xfff0 messages



...


(Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
CERT_VerifyCertificateNow failed [-8179].
(Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
cert_to_ssh_key failed.


-8179 translates to "Peer's certificate issuer is not recognized."
(http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
This means the CA certificate which signed the certificate on the
Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.

Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
this might be the reason why you see this with F24.

To fix this please either add the needed CA certificates to
/etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
[ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
certificates to validate the Smartcard certificate.

I'm working on a fix for SSSD to handle handle this change
automatically, but unfortunately it is not ready yet.


The client installer should be adding the IPA CA to the system certificate
store which should be picked up automagically by OpenSSL and NSS
applications. I think I'd start there to see if that happened.


The responsibility for this was delegated to p11-kit in
11592dde1b232a70f318e01f5271b38890090648. Not sure if it was expected
that p11-kit-proxy will be added to /etc/pki/nssdb by default?


That I'm not sure. Kai might know.

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 certificates expired, please help!

[Petr Vobornik]

On 07/18/2016 05:45 AM, Linov Suresh wrote:
> Thanks for the update Rob. I went back to Jan 20, 2016, restarted CA and 
> certmonger. Look like certificates were renewed. But I'm getting a different 
> error now,
> 
> *ca-error: Internal error: no response to 
> "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=62=true=true".*

Is PKI running? When you change the time, does restart of IPA help?

> 
> [root@caer ~]# getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20111214223243':
>  status: MONITORING
>  stuck: no
>  key pair storage: 
> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
>  
> Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
>  certificate: 
> type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
>  
> Certificate DB'
>  CA: IPA
>  issuer: CN=Certificate Authority,O=TELOIP.NET 
>  subject: CN=caer.teloip.net ,O=TELOIP.NET 
> 
>  expires: 2016-07-18 15:54:36 UTC
>  eku: id-kp-serverAuth
>  pre-save command:
>  post-save command:
>  track: yes
>  auto-renew: yes
> Request ID '20111214223300':
>  status: MONITORING
>  stuck: no
>  key pair storage: 
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>  Certificate 
> DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
>  certificate: 
> type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
>  Certificate 
> DB'
>  CA: IPA
>  issuer: CN=Certificate Authority,O=TELOIP.NET 
>  subject: CN=caer.teloip.net ,O=TELOIP.NET 
> 
>  expires: 2016-07-18 15:54:52 UTC
>  eku: id-kp-serverAuth
>  pre-save command:
>  post-save command:
>  track: yes
>  auto-renew: yes
> Request ID '20111214223316':
>  status: MONITORING
>  stuck: no
>  key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>  certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
> Certificate DB'
>  CA: IPA
>  issuer: CN=Certificate Authority,O=TELOIP.NET 
>  subject: CN=caer.teloip.net ,O=TELOIP.NET 
> 
>  expires: 2016-07-18 15:55:04 UTC
>  eku: id-kp-serverAuth
>  pre-save command:
>  post-save command:
>  track: yes
>  auto-renew: yes
> Request ID '20130519130741':
>  status: MONITORING
>  ca-error: Internal error: no response to 
> "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=61=true=true;.
>  stuck: no
>  key pair storage: 
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert 
> cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
>  certificate: 
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert 
> cert-pki-ca',token='NSS Certificate DB'
>  CA: dogtag-ipa-renew-agent
>  issuer: CN=Certificate Authority,O=TELOIP.NET 
>  subject: CN=CA Audit,O=TELOIP.NET 
>  expires: 2017-10-13 14:10:49 UTC
>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
> "auditSigningCert cert-pki-ca"
>  track: yes
>  auto-renew: yes
> Request ID '20130519130742':
>  status: MONITORING
>  ca-error: Internal error: no response to 
> "http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=60=true=true;.
>  stuck: no
>  key pair storage: 
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert 
> cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
>  certificate: 
> type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert 
> cert-pki-ca',token='NSS Certificate DB'
>  CA: dogtag-ipa-renew-agent
>  issuer: CN=Certificate Authority,O=TELOIP.NET 
>  subject: CN=OCSP Subsystem,O=TELOIP.NET 
>  expires: 2017-10-13 14:09:49 UTC
>  eku: id-kp-OCSPSigning
>  pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
>  post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
> "ocspSigningCert cert-pki-ca"
>  track: yes
>  auto-renew: yes
> Request ID '20130519130743':
>  status: MONITORING
>  ca-error: Internal error: no response to 
> 

Re: [Freeipa-users] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment

[Petr Vobornik]

On 07/18/2016 03:57 PM, Rob Crittenden wrote:
> Grant Wu wrote:
>> Thanks for the information.  Do you know if there are any plans to
>> support cross-realm trust with general KDCs?
> 
> https://fedorahosted.org/freeipa/ticket/4867
> 
> rob

In general, IPA contains krb5 component which can be in theory
configured to trust other krb5 KDC. But this procedure is manual. IPA
doesn't provide any tooling to easy it and it is not tested therefore
not supported. The general Kerberos realm trust is not planned for any
upcoming release mostly because we don't see a big demand for it. Feel
free to cc yourself or add comment to
https://fedorahosted.org/freeipa/ticket/4917 It will raise the visible
demand.

Ticket 4867 is different, it is about IPA-IPA trusts where the scope is
more confined. It may or may not(more probable) allow the trust with
general KDC as a side effect. Demand for IPA-IPA trust is raising so it
is definitively on our radar and has a chance to be implemented in some
of upcoming releases.

For completeness, there is also a RFE to support IPA-SAMBA 4 DC trusts:
https://fedorahosted.org/freeipa/ticket/4866
-- 
Petr Vobornik

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

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

[Sumit Bose]

On Mon, Jul 18, 2016 at 09:54:37AM -0400, Rob Crittenden wrote:
> Sumit Bose wrote:
> > On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:
> > > On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:
> > > > On (16/07/16 10:19), Martin Štefany wrote:
> > > > > 
> > > > > Hello Sumit,
> > > > > 
> > > > > seems that upgrade to F24 broke things again. This time no AVCs, 
> > > > > empty SSSD
> > > > > logs, but same problem: 'Error looking up public keys'.
> > > > > 
> > > > > selinux-policy-3.13.1-191.fc24.3.noarch
> > > > > selinux-policy-targeted-3.13.1-191.fc24.3.noarch
> > > > > sssd-1.13.4-3.fc24.x86_64
> > > > > 
> > > > Fedora 23 and fedora 24 has the same version of sssd
> > > > and almost the same version of openssh.
> > > > I have no idea what coudl broke it it there are not any AVCs.
> > > > 
> > > > > 
> > > > > Using debug_level 0x0250 ::
> > > > > 
> > > > For troubleshooting, it would be better to see all
> > > > debug messages. (debug_level = 0xfff0)
> > > 
> > > Hello Lukas,
> > > 
> > > thanks for replying on this, here are debug_level = 0xfff0 messages
> > > 
> > 
> > ...
> > 
> > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
> > > CERT_VerifyCertificateNow failed [-8179].
> > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] 
> > > (0x0040):
> > > cert_to_ssh_key failed.
> > 
> > -8179 translates to "Peer's certificate issuer is not recognized."
> > (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
> > This means the CA certificate which signed the certificate on the
> > Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.
> > 
> > Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
> > this might be the reason why you see this with F24.
> > 
> > To fix this please either add the needed CA certificates to
> > /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
> > [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
> > certificates to validate the Smartcard certificate.
> > 
> > I'm working on a fix for SSSD to handle handle this change
> > automatically, but unfortunately it is not ready yet.
> 
> The client installer should be adding the IPA CA to the system certificate
> store which should be picked up automagically by OpenSSL and NSS
> applications. I think I'd start there to see if that happened.

The responsibility for this was delegated to p11-kit in
11592dde1b232a70f318e01f5271b38890090648. Not sure if it was expected
that p11-kit-proxy will be added to /etc/pki/nssdb by default?

bye,
Sumit

> 
> 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] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment

[Rob Crittenden]

Grant Wu wrote:

Thanks for the information.  Do you know if there are any plans to
support cross-realm trust with general KDCs?


https://fedorahosted.org/freeipa/ticket/4867

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

[Rob Crittenden]

Sumit Bose wrote:

On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:

On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:

On (16/07/16 10:19), Martin Štefany wrote:


Hello Sumit,

seems that upgrade to F24 broke things again. This time no AVCs, empty SSSD
logs, but same problem: 'Error looking up public keys'.

selinux-policy-3.13.1-191.fc24.3.noarch
selinux-policy-targeted-3.13.1-191.fc24.3.noarch
sssd-1.13.4-3.fc24.x86_64


Fedora 23 and fedora 24 has the same version of sssd
and almost the same version of openssh.
I have no idea what coudl broke it it there are not any AVCs.



Using debug_level 0x0250 ::


For troubleshooting, it would be better to see all
debug messages. (debug_level = 0xfff0)


Hello Lukas,

thanks for replying on this, here are debug_level = 0xfff0 messages



...


(Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
CERT_VerifyCertificateNow failed [-8179].
(Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
cert_to_ssh_key failed.


-8179 translates to "Peer's certificate issuer is not recognized."
(http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
This means the CA certificate which signed the certificate on the
Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.

Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
this might be the reason why you see this with F24.

To fix this please either add the needed CA certificates to
/etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
[ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
certificates to validate the Smartcard certificate.

I'm working on a fix for SSSD to handle handle this change
automatically, but unfortunately it is not ready yet.


The client installer should be adding the IPA CA to the system 
certificate store which should be picked up automagically by OpenSSL and 
NSS applications. I think I'd start there to see if that happened.


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

[Jakub Hrozek]

On Mon, Jul 18, 2016 at 01:36:30PM +, Sullivan, Daniel [AAA] wrote:
> > Are also users that are not part of this group misbehaving?
> 
> Not that I am aware of.  I’ll get you a real answer though.  Are there any 
> known workarounds to the @ problem used to transform group names (i.e. a more 
> robust ‘override_space’ option)?  I looked a the doc briefly but can’t find 
> anything. 

The override_space really just concerns spaces, not @-characters.

> 
> I was thinking maybe could use re_expression to tokenize group names by 
> taking the last token parsed by @ for the domain portion, although this seems 
> kind of hacky, also not sure if it would work.

Yes, I guess this should work.

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

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

[Sullivan, Daniel [AAA]]

> Are also users that are not part of this group misbehaving?

Not that I am aware of.  I’ll get you a real answer though.  Are there any 
known workarounds to the @ problem used to transform group names (i.e. a more 
robust ‘override_space’ option)?  I looked a the doc briefly but can’t find 
anything. 

I was thinking maybe could use re_expression to tokenize group names by taking 
the last token parsed by @ for the domain portion, although this seems kind of 
hacky, also not sure if it would work.

Dan



> On Jul 18, 2016, at 8:23 AM, Jakub Hrozek  wrote:
> 
> On Mon, Jul 18, 2016 at 11:56:24AM +, Sullivan, Daniel [AAA] wrote:
>> Hi, Jakub,
>> 
>> In line with your performance tuning document referenced prior in this
>> thread, I’ve actually already implemented the three configuration changes
>> you specified (prior to identifying this issue).  Right now I am focusing on
>> the use case documented below, because as of right now I am unable to get
>> that user populated into a client cache with sssd 1.14, at all.  In other
>> cases for individual users (prior to implementing tmpfs for example), it
>> seemed like an initial lookup on a client failed, then subsequent lookups
>> would succeed, presumably as a result of the DC eventually looking up and
>> caching the user.  This user (the one I can’t seem to lookup on a client)
>> is a member of a large number of groups, and also some of these groups
>> have longer names with spaces and special characters in them (i.e. $ and
>> . @)   I haven’t gone through and checked if one of these groups has a
>> large number of users, primarily because I am able to lookup users that
>> are members of groups with a large number of members (over 1000) already.
>> This is an actual group that this user is a member of, for example:
>> 
>> 788658174(members of this group will have full mailbox access and send as 
>> rights to 
>> urbj...@health.bsd.uchicago.edu 
>> mailbox)
>> 
>> Right now my theory is that the @ in this group name is causing the lookup 
>> to fail, as it is used as a character to specify the actual domain of a 
>> trusted group, although that has yet to be verified.
> 
> Yes, I would say this is the issue, because sssd tries to split the
> input string into name,domain components according to the re_expression
> value which tries to match anything before the first @ as a groupname
> and the rest as the username.
> 
> Are also users that are not part of this group misbehaving?
> 
>> 
>> NSS - https://gist.github.com/dsulli99/01715234efab09772e8236a13e4f4ef5
>> IPA - https://gist.github.com/dsulli99/f3cc92d7c32061fd4676a83a039c31b1
>> 
>> Here is the full list of groups the user is a member of, from the output of 
>> the id command on a DC:
>> 
>> uid=339741696(hah...@bsdad.uchicago.edu) 
>> gid=339741696(hah...@bsdad.uchicago.edu) 
>> groups=339741696(hah...@bsdad.uchicago.edu),788655857(hsd$
>>  kcbd 6260 conference room freebusy 
>> r...@bsdad.uchicago.edu),788668882(phs 
>> phsapps remoteapp default 
>> a...@bsdad.uchicago.edu),788670425(phs 
>> phsapps notepad2 
>> us...@bsdad.uchicago.edu),788670429(phs 
>> phsapps cmd 
>> us...@bsdad.uchicago.edu),339797692(cri-hpc_allus...@bsdad.uchicago.edu),788670440(phs
>>  phsapps r v3.2.0 32-bit 
>> us...@bsdad.uchicago.edu),788672389(phs 
>> phsapps remote desktop 
>> us...@bsdad.uchicago.edu),788655856(hsd$ 
>> w230 conference room freebusy 
>> r...@bsdad.uchicago.edu),788670441(phs 
>> phsapps r v3.2.0 64-bit 
>> us...@bsdad.uchicago.edu),788672413(phs 
>> phsapps r v3.2.3 64-bit 
>> us...@bsdad.uchicago.edu),788670431(phs 
>> phsapps file explorer 
>> us...@bsdad.uchicago.edu),788670428(phs 
>> phsapps adobe reader xi 
>> us...@bsdad.uchicago.edu),788609545(adm-trackitus...@bsdad.uchicago.edu),788615356(hsd$
>>  workstation local 
>> lo...@bsdad.uchicago.edu),339794097(cri-lmem_cri_us...@bsdad.uchicago.edu),788670445(phs
>>  phsapps taskmgr 
>> us...@bsdad.uchicago.edu),788624309(hsd$ 
>> pr...@bsdad.uchicago.edu),788670436(phs 
>> phsapps notepadplusplus 
>> us...@bsdad.uchicago.edu),788654299(cri-all_gro...@bsdad.uchicago.edu),788670434(phs
>>  phsapps notepad users@bsdad

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

[Jakub Hrozek]

On Mon, Jul 18, 2016 at 11:56:24AM +, Sullivan, Daniel [AAA] wrote:
> Hi, Jakub,
> 
> In line with your performance tuning document referenced prior in this
> thread, I’ve actually already implemented the three configuration changes
> you specified (prior to identifying this issue).  Right now I am focusing on
> the use case documented below, because as of right now I am unable to get
> that user populated into a client cache with sssd 1.14, at all.  In other
> cases for individual users (prior to implementing tmpfs for example), it
> seemed like an initial lookup on a client failed, then subsequent lookups
> would succeed, presumably as a result of the DC eventually looking up and
> caching the user.  This user (the one I can’t seem to lookup on a client)
> is a member of a large number of groups, and also some of these groups
> have longer names with spaces and special characters in them (i.e. $ and
> . @)   I haven’t gone through and checked if one of these groups has a
> large number of users, primarily because I am able to lookup users that
> are members of groups with a large number of members (over 1000) already.
> This is an actual group that this user is a member of, for example:
> 
> 788658174(members of this group will have full mailbox access and send as 
> rights to 
> urbj...@health.bsd.uchicago.edu 
> mailbox)
> 
> Right now my theory is that the @ in this group name is causing the lookup to 
> fail, as it is used as a character to specify the actual domain of a trusted 
> group, although that has yet to be verified.

Yes, I would say this is the issue, because sssd tries to split the
input string into name,domain components according to the re_expression
value which tries to match anything before the first @ as a groupname
and the rest as the username.

Are also users that are not part of this group misbehaving?

> 
> NSS - https://gist.github.com/dsulli99/01715234efab09772e8236a13e4f4ef5
> IPA - https://gist.github.com/dsulli99/f3cc92d7c32061fd4676a83a039c31b1
> 
> Here is the full list of groups the user is a member of, from the output of 
> the id command on a DC:
> 
> uid=339741696(hah...@bsdad.uchicago.edu) 
> gid=339741696(hah...@bsdad.uchicago.edu) 
> groups=339741696(hah...@bsdad.uchicago.edu),788655857(hsd$
>  kcbd 6260 conference room freebusy 
> r...@bsdad.uchicago.edu),788668882(phs 
> phsapps remoteapp default 
> a...@bsdad.uchicago.edu),788670425(phs 
> phsapps notepad2 
> us...@bsdad.uchicago.edu),788670429(phs 
> phsapps cmd 
> us...@bsdad.uchicago.edu),339797692(cri-hpc_allus...@bsdad.uchicago.edu),788670440(phs
>  phsapps r v3.2.0 32-bit 
> us...@bsdad.uchicago.edu),788672389(phs 
> phsapps remote desktop 
> us...@bsdad.uchicago.edu),788655856(hsd$ 
> w230 conference room freebusy 
> r...@bsdad.uchicago.edu),788670441(phs 
> phsapps r v3.2.0 64-bit 
> us...@bsdad.uchicago.edu),788672413(phs 
> phsapps r v3.2.3 64-bit 
> us...@bsdad.uchicago.edu),788670431(phs 
> phsapps file explorer 
> us...@bsdad.uchicago.edu),788670428(phs 
> phsapps adobe reader xi 
> us...@bsdad.uchicago.edu),788609545(adm-trackitus...@bsdad.uchicago.edu),788615356(hsd$
>  workstation local 
> lo...@bsdad.uchicago.edu),339794097(cri-lmem_cri_us...@bsdad.uchicago.edu),788670445(phs
>  phsapps taskmgr 
> us...@bsdad.uchicago.edu),788624309(hsd$ 
> pr...@bsdad.uchicago.edu),788670436(phs 
> phsapps notepadplusplus 
> us...@bsdad.uchicago.edu),788654299(cri-all_gro...@bsdad.uchicago.edu),788670434(phs
>  phsapps notepad 
> us...@bsdad.uchicago.edu),788670438(phs 
> phsapps plink 1.90 
> us...@bsdad.uchicago.edu),788670427(phs 
> phsapps office access 2013 
> us...@bsdad.uchicago.edu),788655855(hsd$ 
> w229 conference room freebusy 
> r...@bsdad.uchicago.edu),788635799(adm-sde-clie...@bsdad.uchicago.edu),788670439(phs
>  phsapps office powerpoint 2013 
> u...@bsdad.uchicago.edu),788610792(hsd$ all 
> health 
> stud...@bsdad.uchicago.edu),788655854(hsd$ 
> n102 conference 

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

[Sullivan, Daniel [AAA]]

Hi, Jakub,

In line with your performance tuning document referenced prior in this thread, 
I’ve actually already implemented the three configuration changes you specified 
(prior to identifying this issue).  Right now I am focusing on the use case 
documented below, because as of right now I am unable to get that user 
populated into a client cache with sssd 1.14, at all.  In other cases for 
individual users (prior to implementing tmpfs for example), it seemed like an 
initial lookup on a client failed, then subsequent lookups would succeed, 
presumably as a result of the DC eventually looking up and caching the user.  
This user (the one I can’t seem to lookup on a client) is a member of a large 
number of groups, and also some of these groups have longer names with spaces 
and special characters in them (i.e. $ and . @)   I haven’t gone through and 
checked if one of these groups has a large number of users, primarily because I 
am able to lookup users that are members of groups with a large number of 
members (over 1000) already.  This is an actual group that this user is a 
member of, for example:

788658174(members of this group will have full mailbox access and send as 
rights to 
urbj...@health.bsd.uchicago.edu mailbox)

Right now my theory is that the @ in this group name is causing the lookup to 
fail, as it is used as a character to specify the actual domain of a trusted 
group, although that has yet to be verified.

NSS - https://gist.github.com/dsulli99/01715234efab09772e8236a13e4f4ef5
IPA - https://gist.github.com/dsulli99/f3cc92d7c32061fd4676a83a039c31b1

Here is the full list of groups the user is a member of, from the output of the 
id command on a DC:

uid=339741696(hah...@bsdad.uchicago.edu) 
gid=339741696(hah...@bsdad.uchicago.edu) 
groups=339741696(hah...@bsdad.uchicago.edu),788655857(hsd$
 kcbd 6260 conference room freebusy 
r...@bsdad.uchicago.edu),788668882(phs phsapps 
remoteapp default 
a...@bsdad.uchicago.edu),788670425(phs phsapps 
notepad2 
us...@bsdad.uchicago.edu),788670429(phs 
phsapps cmd 
us...@bsdad.uchicago.edu),339797692(cri-hpc_allus...@bsdad.uchicago.edu),788670440(phs
 phsapps r v3.2.0 32-bit 
us...@bsdad.uchicago.edu),788672389(phs 
phsapps remote desktop 
us...@bsdad.uchicago.edu),788655856(hsd$ w230 
conference room freebusy 
r...@bsdad.uchicago.edu),788670441(phs phsapps 
r v3.2.0 64-bit 
us...@bsdad.uchicago.edu),788672413(phs 
phsapps r v3.2.3 64-bit 
us...@bsdad.uchicago.edu),788670431(phs 
phsapps file explorer 
us...@bsdad.uchicago.edu),788670428(phs 
phsapps adobe reader xi 
us...@bsdad.uchicago.edu),788609545(adm-trackitus...@bsdad.uchicago.edu),788615356(hsd$
 workstation local 
lo...@bsdad.uchicago.edu),339794097(cri-lmem_cri_us...@bsdad.uchicago.edu),788670445(phs
 phsapps taskmgr 
us...@bsdad.uchicago.edu),788624309(hsd$ 
pr...@bsdad.uchicago.edu),788670436(phs 
phsapps notepadplusplus 
us...@bsdad.uchicago.edu),788654299(cri-all_gro...@bsdad.uchicago.edu),788670434(phs
 phsapps notepad us...@bsdad.uc
hicago.edu),788670438(phs phsapps plink 1.90 
us...@bsdad.uchicago.edu),788670427(phs 
phsapps office access 2013 
us...@bsdad.uchicago.edu),788655855(hsd$ w229 
conference room freebusy 
r...@bsdad.uchicago.edu),788635799(adm-sde-clie...@bsdad.uchicago.edu),788670439(phs
 phsapps office powerpoint 2013 
u...@bsdad.uchicago.edu),788610792(hsd$ all 
health 
stud...@bsdad.uchicago.edu),788655854(hsd$ 
n102 conference room freebusy 
r...@bsdad.uchicago.edu),339793627(cri-galaxy_web_us...@bsdad.uchicago.edu),788670444(phs
 phsapps statamp 14 
us...@bsdad.uchicago.edu),339792922(cri-all_us...@bsdad.uchicago.edu),788670442(phs
 phsapps rstudio 
us...@bsdad.uchicago.edu),788655852(hsd$ 
freebusy read for all conference 

[Freeipa-users] IPA certificates expired, please help!

[Linov Suresh]

I logged into my IPA master, and found that the cert had expired again, we 
renewed these certificates about 18 months ago.



Our environment is CentOS 6.4 and IPA 3.0.0-26.



I followed the Redhat documentation, How do I manually renew Identity 
Management (IPA) certificates after they have expired? (Master IPA Server), 
https://access.redhat.com/solutions/643753 but no luck.

I have also changed "NSSEnforceValidCerts off" in /etc/httpd/conf.d/nss.conf 
and the  nsslapd-validate-cert value is warn.
ldapsearch -x -h localhost -p 7389 -D 'cn=directory manager' -w *** -b  
cn=config | grep  nsslapd-validate-cert
nsslapd-validate-cert: warn

Here is my getcert list,

[root@caer ~]# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20111214223243':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed to 
execute the HTTP POST transaction.  Peer certificate cannot be authenticated 
with known CA certificates).
stuck: yes
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-TELOIP-NET//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-TELOIP-NET',nickname='Server-Cert',token='NSS
 Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=caer.teloip.net,O=TELOIP.NET
expires: 2016-01-29 14:09:46 UTC
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20111214223300':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed to 
execute the HTTP POST transaction.  Peer certificate cannot be authenticated 
with known CA certificates).
stuck: yes
key pair storage: 
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
 Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS
 Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=caer.teloip.net,O=TELOIP.NET
expires: 2016-01-29 14:09:45 UTC
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20111214223316':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl failed to 
execute the HTTP POST transaction.  Peer certificate cannot be authenticated 
with known CA certificates).
stuck: yes
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=caer.teloip.net,O=TELOIP.NET
expires: 2016-01-29 14:09:45 UTC
eku: id-kp-serverAuth
pre-save command:
post-save command:
track: yes
auto-renew: yes
Request ID '20130519130741':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
certificate: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=CA Audit,O=TELOIP.NET
expires: 2017-10-13 14:10:49 UTC
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"auditSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130519130742':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS Certificate DB',pin='297100916664'
certificate: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert 
cert-pki-ca',token='NSS Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=TELOIP.NET
subject: CN=OCSP Subsystem,O=TELOIP.NET
expires: 2017-10-13 14:09:49 UTC
eku: id-kp-OCSPSigning
pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad
post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert 
"ocspSigningCert cert-pki-ca"
track: yes
auto-renew: yes
Request ID '20130519130743':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert 
cert-pki-ca',token='NSS 

Re: [Freeipa-users] Migrating to FreeIPA from an existing Heimdal Kerberos and 389-ds deployment

[Grant Wu]

Thanks for the information.  Do you know if there are any plans to support
cross-realm trust with general KDCs?
-- 
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] non-authoritative tricks for DNS resolution

[Petr Spacek]

On 18.7.2016 03:25, Sullivan, Daniel [AAA] wrote:
> Would a DNS view (bind) work?
> 
> http://docstore.mik.ua/orelly/networking_2ndEd/dns/ch10_06.htm
> 
> Also, depending on what you are using for NAT, some devices will mangle the 
> reply payload of A record lookups as they traverse NAT to avoid haripinning 
> (a packet going out and then back in the same interface as it traverses NAT). 
>  This is known as DNS doctoring, at least in the world of Cisco.
> 
> http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/72273-dns-doctoring-3zones.html
> 
> Let me know if either of those will solve your problem.  If not, I might have 
> a misunderstanding of what you are asking.
> 
> Dan
> 
>> On Jul 17, 2016, at 3:36 PM, Brendan Kearney  wrote:
>>
>> i am looking to setup a VPN in order to access some resources, and want to 
>> point my clients at this resource via DNS.  the resource i am accessing is 
>> internet resolvable, but i am accessing it via the VPN, and using a NAT for 
>> the VPN (full 1-to-1 or static NAT).  i want to have a record in my DNS for 
>> this resource, using its proper name (which i am not authoritative for), but 
>> assign it the IP of my NAT.
>>
>> say for example, host.domain-ext.tld is the resource i want to access, and 
>> it resolves externally to 1.2.3.4.  my VPN NAT would be 192.168.99.137.  i 
>> want internal resolution of DNS to point to 192.168.99.137 so the network 
>> routing takes my internal clients to the VPN and not out to the internet.
>>
>> i am using isc bind, bind-dyndb-ldap, and fedora, but not freeipa, for dns.  
>> how do i setup the zone and record to accomplish this DNS trick?  i have 
>> talked with some DNS gurus and they indicate that i can do something with 
>> the "@" record.  it seems that the record i want, would be its own zone, and 
>> the @ record would point to the name, and the SOA would be the NAT IP.  i 
>> could be wrong about the details, but something like this is how to setup 
>> resolution the way i want.
>>
>> any pointers would be greatly appreciated.

Background note:
All these DNS tricks are hacks to work around IP routing problem in
configuration you described.

If you really want to use DNS tricks, you can create a DNS zone with name
equal to the you want to override and will this zone with A/ record at
zone apex (@).
The DNS approach has some inherent advantages:

1. All DNS names below the name you want to 'hijack' will not be resolvable in
your network. E.g. if the name is hijacked.example.com. then sub-domains like
anything.hijacked.example.com. will not be resolvable.

2. Your clients will go securely over VPN if and only if they use your local
DNS servers. Any client configured (even accidentally) to use some other DNS
server (e.g. public 8.8.8.8) will get the 'public' address and do not tunnel
the traffic over VPN.


Secure and reliable solution is not to use DNS but solve things on IP layer:
On the network gateway, configure IPSec tunnel (or any other VPN) in a way
that *the original IP address* is routed over VPN.

This does not require any DNS tricks and thus will work regardless of client
configuration.

I hope it helps.

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

[Martin Štefany]

On 7/18/2016 9:50 AM, Sumit Bose wrote:

On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:

On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:

On (16/07/16 10:19), Martin Štefany wrote:


Hello Sumit,

seems that upgrade to F24 broke things again. This time no AVCs, empty SSSD
logs, but same problem: 'Error looking up public keys'.

selinux-policy-3.13.1-191.fc24.3.noarch
selinux-policy-targeted-3.13.1-191.fc24.3.noarch
sssd-1.13.4-3.fc24.x86_64


Fedora 23 and fedora 24 has the same version of sssd
and almost the same version of openssh.
I have no idea what coudl broke it it there are not any AVCs.



Using debug_level 0x0250 ::


For troubleshooting, it would be better to see all
debug messages. (debug_level = 0xfff0)


Hello Lukas,

thanks for replying on this, here are debug_level = 0xfff0 messages



...


(Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
CERT_VerifyCertificateNow failed [-8179].
(Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
cert_to_ssh_key failed.


-8179 translates to "Peer's certificate issuer is not recognized."
(http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
This means the CA certificate which signed the certificate on the
Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.

Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
this might be the reason why you see this with F24.

To fix this please either add the needed CA certificates to
/etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
[ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
certificates to validate the Smartcard certificate.


Thank you!
Fixed for now by putting 'ca_db = /etc/ipa/nssdb' to the [ssh] section 
of sssd.conf, but CA certificate is actually the one from IPA CA, as 
this SSH key is generated from my userCertificate. Works like a charm.


Kind regards,
Martin



I'm working on a fix for SSSD to handle handle this change
automatically, but unfortunately it is not ready yet.

HTH

bye,
Sumit





$ /usr/bin/sss_ssh_authorizedkeys martin
Error looking up public keys


And try to run strace with sss_ssh_authorizedkeys

LS


Martin


--
--
Martin

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

Re: [Freeipa-users] Error in selinux child: libsemanage can't parse spaces in AD user names

[Jakub Hrozek]

On Mon, Jul 18, 2016 at 09:33:35AM +1000, Lachlan Musicman wrote:
> Ok, I've just spoken with my colleague that has been involved in the IPA
> roll out, and he said he thought that override_space wasn't compatible with
> ID overrides?

I haven't tested that to be honest. But just using my knowledge of the
code as a basis, I would say the two should be compatible, especially
with 1.14.0 where we decoupled the output from how we store users. But
again, I haven't tested any of this.

> 
> Either way, since we have a working system we are reticent to make too many
> changes - soon we will have a test system in place and I will be able to
> check it then?

selinux_provider=none should be an easy workaround if you don't use the
SELinux labels. I still have an item on my todo list to test this
locally, I think I will get to that this week.

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

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

[Jakub Hrozek]

On Fri, Jul 15, 2016 at 04:35:54PM +, Sullivan, Daniel [AAA] wrote:
> 
> Jakub,
> 
> Thank you for replying to me.  Before I forget I will say that I am still on 
> sssd 1.13 on the domain controller; I didn’t upgrade it because I haven’t had 
> any problems logging into that system yet.  That being said:
> 
> Thank you, but did this command return "No such user” ?
> 
> Yes.  Whenever this occurs "No such user" is the result from the id command 
> executed on the client.
> 
> If it did, was the user cached previously (iow, was there a successfull
> lookup before) ?
> 
> No, this is the first time the user has ever been looked up.  As far as I 
> know the user has never been successfully entered into the cache.  Similarly, 
> the user has never logged in to the IPA server via an SSSD client.

Ah, thank you, if the user has not been cached before, then it's
expected that the lookup has nothing to fall back to if the client fails
to look up information from the server.

> 
> Here is an example of a failed lookup from a client:
> 
> [root@cri-kcriwebgdp1 problem]# id hahsan
> id: hahsan: No such user
> 
> The DC logs for this operation are
> NSS - https://gist.github.com/dsulli99/01715234efab09772e8236a13e4f4ef5
> IPA - https://gist.github.com/dsulli99/f3cc92d7c32061fd4676a83a039c31b1

Thank you, I see that there is quite a lot of groups and the lookup
takes a bit of time. I wonder if any of the groups the user is a member
of are large?

If yes (and since moving the cache to tmpfs had helped), I wonder if
also using ignore_group_members would mitigate the issue further, like
this:

subdomain_inherit = ignore_group_members, ldap_purge_cache_timeout
ignore_group_members = True
ldap_purge_cache_timeout = 0

These would go into the domain section on the server itself.

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

Re: [Freeipa-users] HBAC and AD users

[Jakub Hrozek]

On Mon, Jul 18, 2016 at 09:17:06AM +1000, Lachlan Musicman wrote:
> Previously we did have the default_domain_suffix set, but we had to unset
> it. I can't remember why we had to - something to do with
> ownership/permissions and our filesystem (IBM v7000) not playing nice iirc.
> We really wanted to use the dds => the researchers are complaining of
> broken brains due to the new concept of "ssh us...@domain.com@ipa.domain.com".
> I will need to teach ssh config.

OK, in the versions before 1.14 it was quite hard (read: impossible) to
set short names for trusted users on the clients.

On the IDM servers, you should still use long names for output, because
that's what the IPA plugins expect, but on the clients, it should be
possible to set shortnames with the full_name_format.

-- 
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 Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:
> On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:
> > On (16/07/16 10:19), Martin Štefany wrote:
> > > 
> > > Hello Sumit,
> > > 
> > > seems that upgrade to F24 broke things again. This time no AVCs, empty 
> > > SSSD
> > > logs, but same problem: 'Error looking up public keys'.
> > > 
> > > selinux-policy-3.13.1-191.fc24.3.noarch
> > > selinux-policy-targeted-3.13.1-191.fc24.3.noarch
> > > sssd-1.13.4-3.fc24.x86_64
> > > 
> > Fedora 23 and fedora 24 has the same version of sssd
> > and almost the same version of openssh.
> > I have no idea what coudl broke it it there are not any AVCs.
> > 
> > > 
> > > Using debug_level 0x0250 ::
> > > 
> > For troubleshooting, it would be better to see all
> > debug messages. (debug_level = 0xfff0)
> 
> Hello Lukas,
> 
> thanks for replying on this, here are debug_level = 0xfff0 messages
> 

...

> (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
> CERT_VerifyCertificateNow failed [-8179].
> (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
> cert_to_ssh_key failed.

-8179 translates to "Peer's certificate issuer is not recognized."
(http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
This means the CA certificate which signed the certificate on the
Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.

Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
this might be the reason why you see this with F24.

To fix this please either add the needed CA certificates to
/etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
[ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
certificates to validate the Smartcard certificate. 

I'm working on a fix for SSSD to handle handle this change
automatically, but unfortunately it is not ready yet.

HTH

bye,
Sumit

> 
> > > 
> > > $ /usr/bin/sss_ssh_authorizedkeys martin
> > > Error looking up public keys
> > > 
> > And try to run strace with sss_ssh_authorizedkeys
> > 
> > LS
> 
> Martin

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