Re: [Freeipa-users] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Rob Crittenden]

Michael Plemmons wrote:
> I just realized that I sent the reply directly to Rob and not to the
> list.  My response is inline

Ok, this is actually good news.

I made a similar proposal in another case and I was completely wrong.
Flo had the user do something and it totally fixed their auth error, I
just can't remember what it was or find the e-mail thread. I'm pretty
sure it was this calendar year though.

rob

> 
> 
> 
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> *
> 614.427.2411
> mike.plemm...@crosschx.com 
> www.crosschx.com 
> 
> On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons
> mailto:michael.plemm...@crosschx.com>>
> wrote:
> 
> 
> 
> 
> 
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> *
> 614.427.2411
> mike.plemm...@crosschx.com 
> www.crosschx.com 
> 
> On Thu, May 4, 2017 at 9:24 AM, Rob Crittenden  > wrote:
> 
> Michael Plemmons wrote:
> > I realized that I was not very clear in my statement about
> testing with
> > ldapsearch.  I had initially run it without logging in with a
> DN.  I was
> > just running the local ldapsearch -x command.  I then tested on
> > ipa12.mgmt and ipa11.mgmt logging in with a full DN for the
> admin and
> > "cn=Directory Manager" from ipa12.mgmt (broken server) and
> ipa11.mgmt
> > and both ldapsearch command succeeded.
> >
> > I ran the following from ipa12.mgmt and ipa11.mgmt as a non
> root user.
> > I also ran the command showing a line count for the output and
> the line
> > counts for each were the same when run from ipa12.mgmt and
> ipa11.mgmt.
> >
> > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
> 
> >  > -D "DN" -w PASSWORD -b
> > "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
> >
> > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
> 
> >  > -D "cn=directory manager" -w
> PASSWORD dn
> 
> The CA has its own suffix and replication agreements. Given the auth
> error and recent (5 months) renewal of CA credentials I'd check
> that the
> CA agent authentication entries are correct.
> 
> Against each master with a CA run:
> 
> $ ldapsearch -LLL -x -D 'cn=directory manager' -W -b
> uid=ipara,ou=people,o=ipaca description
> 
> The format is 2;serial#,subject,issuer
> 
> Then on each run:
> 
> # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial
> 
> The serial # should match that in the description everywhere.
> 
> rob
> 
> 
> 
> On the CA (IPA13.MGMT) I ran the ldapsearch command and see that the
> serial number is 7.  I then ran the certutil command on all three
> servers and the serial number is 7 as well.
> 
>  
> I also ran the ldapsearch command against the other two servers and
> they also showed a serial number of 7. 
> 
>  
> 
> 
> >
> >
> >
> >
> >
> > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
> > *
> > 614.427.2411
> > mike.plemm...@crosschx.com 
>  >
> > www.crosschx.com 
> 
> >
> > On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons
> >  
>  >>
> > wrote:
> >
> > I have a three node IPA cluster.
> >
> > ipa11.mgmt - was a master over 6 months ago
> > ipa13.mgmt - current master
> > ipa12.mgmt
> >
> > ipa13 has agreements with ipa11 and ipa12.  ipa11 and
> ipa12 do not
> > have agreements between each other.
> >
> > It appears that either ipa12.mgmt lost some level of its
> replication
> > agreement with ipa13.  I saw some level because users /
> hosts were
> > replicated between all systems but we started seeing DNS
> was not
> > resolving properly from ipa12.  I do not know when this
> started.
> >
> > When looking at replication agreements on ipa12 I did not
> see any
> > agreement with ipa13.
> >
> > When I run ipa-replica-manag

Re: [Freeipa-users] how to setup freeipa project to local environment

[Rob Crittenden]

rajkumar wrote:
> Hello freeipa team,
> 
> I have download freeipa4.4.4.tar.gz and I need to setup  freeipa project
> as a local environment(to customize via IDE like eclipse) for
> customization. suggest me how can do that. or any reference link.

I'd start with the BUILD file in the tree.

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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

On 03/05/2017 15:05, Brian Candler wrote:
It turns out we had another 16.04 machine which was working fine. But 
as soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 
1.8.16-0ubuntu1.3, it stopped working too.


So it looks like I have a reproducing case for this and I can 
investigate further 


FYI, I finally got to the bottom of this issue.

(1) The groups referred to in the sudo rule had been created as 
non-posix groups in FreeIPA


(2) It seems that the old sudo in Ubuntu wasn't checking groups at all, 
and the new one did.  But it could not see non-posix groups.


(3) I solved the problem by adding "objectClass: posixgroup" and 
"gidNumber: NN" to the groups.


More details at:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1688034/comments/4

Aside: I discovered that the way to debug the sudoers plugin is like this:

Debug sudo /var/log/sudo-debug all@info
Debug sudoers.so /var/log/sudoers-debug all@info

(I had originally missed off the ".so" suffix)

It's a bit frightening that sudo+sssd was not enforcing policies 
correctly, for who knows how long.


Regards,

Brian.

-- 
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] Need LDAP access for host not in IPA domain

[Rob Crittenden]

Detlev Habicht wrote:
> Hello,
> 
> i need a simple, plain LDAP bind for authentication for a host,
> which is not part of my IPA domain.
> 
> Something like this is working in the domain:
> 
>  ldapsearch -vx -H ldaps://xxx.yyy.intern -b "cn=accounts,dc=yyy,dc=intern"
> 
> My problem is, it is only working with the hostname xxx.yyy.intern which
> is part of my domain yyy.intern. But outside of the domain i have to
> use the IP address or something like xxx.yyy.zzz.de
>  .
> 
> But than i have this error message:
> 
> ldap_initialize( ldaps://xxx.yyy.zzz.de:636/??base )
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
> 
> Any idea what i can do?
> 
> Thank you!
> 
> Detlev
> 
> P.S.: I have the same problem in the domain, when i am not using 
>   xxx.yyy.intern. IP address for example is also not working.

I'd slap a -d 255 onto that command. It will give you a lot more
information on what is going on. It could be rejecting the request
because the requested name (IP address) doesn't match anything in the cert.

The 389-ds access log will also confirm whether you are making a
connection or not (to rule out firewall, etc). Note that this log is
buffered so you need to be patient, tail -f won't show connections
immediately.

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] Could not connect to LDAP server host - IO Error creating JSS SSL Socket:

[Michael Plemmons]

I just realized that I sent the reply directly to Rob and not to the list.
My response is inline




*Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
614.427.2411
mike.plemm...@crosschx.com
www.crosschx.com

On Thu, May 4, 2017 at 9:39 AM, Michael Plemmons <
michael.plemm...@crosschx.com> wrote:

>
>
>
>
>
> *Mike Plemmons | Senior DevOps Engineer | CROSSCHX*
> 614.427.2411
> mike.plemm...@crosschx.com
> www.crosschx.com
>
> On Thu, May 4, 2017 at 9:24 AM, Rob Crittenden 
> wrote:
>
>> Michael Plemmons wrote:
>> > I realized that I was not very clear in my statement about testing with
>> > ldapsearch.  I had initially run it without logging in with a DN.  I was
>> > just running the local ldapsearch -x command.  I then tested on
>> > ipa12.mgmt and ipa11.mgmt logging in with a full DN for the admin and
>> > "cn=Directory Manager" from ipa12.mgmt (broken server) and ipa11.mgmt
>> > and both ldapsearch command succeeded.
>> >
>> > I ran the following from ipa12.mgmt and ipa11.mgmt as a non root user.
>> > I also ran the command showing a line count for the output and the line
>> > counts for each were the same when run from ipa12.mgmt and ipa11.mgmt.
>> >
>> > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
>> >  -D "DN" -w PASSWORD -b
>> > "cn=users,cn=accounts,dc=mgmt,dc=crosschx,dc=com" dn
>> >
>> > ldapsearch -LLL -h ipa12.mgmt.crosschx.com
>> >  -D "cn=directory manager" -w PASSWORD
>> dn
>>
>> The CA has its own suffix and replication agreements. Given the auth
>> error and recent (5 months) renewal of CA credentials I'd check that the
>> CA agent authentication entries are correct.
>>
>> Against each master with a CA run:
>>
>> $ ldapsearch -LLL -x -D 'cn=directory manager' -W -b
>> uid=ipara,ou=people,o=ipaca description
>>
>> The format is 2;serial#,subject,issuer
>>
>> Then on each run:
>>
>> # certutil -L -d /etc/httpd/alias -n ipaCert |grep Serial
>>
>> The serial # should match that in the description everywhere.
>>
>> rob
>>
>>
>
> On the CA (IPA13.MGMT) I ran the ldapsearch command and see that the
> serial number is 7.  I then ran the certutil command on all three servers
> and the serial number is 7 as well.
>
>
> I also ran the ldapsearch command against the other two servers and they
> also showed a serial number of 7.
>

>

> >
>> >
>> >
>> >
>> >
>> > *Mike Plemmons | Senior DevOps Engineer | CROSSCHX
>> > *
>> > 614.427.2411
>> > mike.plemm...@crosschx.com 
>> > www.crosschx.com 
>> >
>> > On Wed, May 3, 2017 at 5:28 PM, Michael Plemmons
>> > mailto:michael.plemm...@crosschx.com>>
>> > wrote:
>> >
>> > I have a three node IPA cluster.
>> >
>> > ipa11.mgmt - was a master over 6 months ago
>> > ipa13.mgmt - current master
>> > ipa12.mgmt
>> >
>> > ipa13 has agreements with ipa11 and ipa12.  ipa11 and ipa12 do not
>> > have agreements between each other.
>> >
>> > It appears that either ipa12.mgmt lost some level of its replication
>> > agreement with ipa13.  I saw some level because users / hosts were
>> > replicated between all systems but we started seeing DNS was not
>> > resolving properly from ipa12.  I do not know when this started.
>> >
>> > When looking at replication agreements on ipa12 I did not see any
>> > agreement with ipa13.
>> >
>> > When I run ipa-replica-manage list all three hosts show has master.
>> >
>> > When I run ipa-replica-manage ipa11.mgmt I see ipa13.mgmt is a
>> replica.
>> >
>> > When I run ipa-replica-manage ipa12.mgmt nothing returned.
>> >
>> > I ran ipa-replica-manage connect --cacert=/etc/ipa/ca.crt
>> > ipa12.mgmt.crosschx.com 
>> > ipa13.mgmt.crosschx.com  on
>> ipa12.mgmt
>> >
>> > I then ran the following
>> >
>> > ipa-replica-manage force-sync --from ipa13.mgmt.crosschx.com
>> > 
>> >
>> > ipa-replica-manage re-initialize --from ipa13.mgmt.crosschx.com
>> > 
>> >
>> > I was still seeing bad DNS returns when dig'ing against ipa12.mgmt.
>> > I was able to create user and DNS records and see the information
>> > replicated properly across all three nodes.
>> >
>> > I then ran ipactl stop on ipa12.mgmt and then ipactl start on
>> > ipa12.mgmt because I wanted to make sure everything was running
>> > fresh after the changes above.  While IPA was staring up (DNS
>> > started) we were able to see valid DNS queries returned but
>> > pki-tomcat would not start.
>> >
>> > I am not sure what I need to do in order to get this working.  I
>> > have included the output of certutil and getcert below from all
>> > three servers as well as the debug output for pki.
>> >
>> >
>> > While the IPA system is coming up I am able to successfully run
>> > ldapsearch -x as the root user 

Re: [Freeipa-users] CA lost on migration

[Marius Bjørnstad]

Seems like it works now, almost perfectly.

I was able to get ipa-ca-install to run using an old replica package file 
(replica-info-xxx.gpg), by hacking the script to disable a check for existing 
CA, and by deleting things left over from the failed installation:
- Certs in /etc/httpd/alias and another location using:
certutil -d /etc/httpd/alias -D  "REALM_NAME IPA CA"
certutil -d /etc/httpd/alias -D  ipaCert

- The PKI instance: pkidestroy -s CA -i pki-tomcat
- Dogtag tracking requests: from the date of CA installation.

The command failed when trying to replicate to LDAP because the configuration 
files in /etc/ipa/default.conf. Step 26, migrating certificate profiles to LDAP 
stopped. I then edited /etc/ipa/default.conf so that ca_host points to the 
current host (this was pointing to the old CA host). This made the installation 
script significantly faster, and it completed all 30 steps. It did however 
produce an error about "subject public key info mismatch" for the cert named 
"REALM_NAME IPA CA". (REALM_NAME is the name of the domain in all caps).

Then most things worked, even: # ipa-cacert-manage renew

Couldn't join new clients, as it was downloading the old CA cert from LDAP (I 
had just renewed it). I updated the CA cert in LDAP under "REALM, etc, ipa, 
certificates, REALM IPA CA" by deleting it and calling 
certstore.put_ca_cert_nss in a similar way that was done in 
/usr/lb/python2.7/site-packages/ipaserver/install/ca.py. (when I tried to 
update the cert, not delete if first, I got Subject public key mismatch error, 
exactly same as after the CA installation!)

I could then successfully enroll the other server as clients, then promoted one 
to a master, then installed the CA on that one too. The CA installation 
completed, but step 15 "Failed to restart the dogtag instance". I don't think 
it looks good that my primary master only has "managed suffixes" = domain, and 
the secondary one has domain and ca, in the Web UI, but I will leave it. 
Everything works well now.

I realise that FreeIPA is a complex piece of software, which has been developed 
intensely over the last years, but I really hope that going forward it could 
become more stable, and that upgrading to the next RHEL version from 7 will be 
less of a nightmare. 

Marius


> 3. mai 2017 kl. 17.26 skrev Marius Bjørnstad :
> 
> Hi,
> 
> I have migrated some FreeIPA servers from 3.0.0-51 to 4.4.0-14 by adding new 
> replicas. There were a lot of issues, and I'm strugglig a bit with a 
> configuration management system set up by a central IT department, which 
> overrides files like sssd.conf, and I have to make exceptions to the policy. 
> I hope someone could take the time to help me with this anyway.
> 
> I was able to join both new RHEL 7 machines, and remove one of the old RHEL 6 
> machines, but then I couldn't remove the last one, and couldn't install the 
> CA on any of the new masters. I (perhaps stupidly) removed the old server 
> using ldapdelete, based on this thread: 
> https://www.redhat.com/archives/freeipa-users/2012-June/msg00382.html. I 
> thought that if I could get rid of the old stuff, I may be able to 
> successfully promote one of the new servers to CA master. The command to 
> install the CA almost completed successfully on the first master, but stopped 
> on one of the last steps.
> 
> Now I get:
> # ipa-ca-install
> CA is already installed on this host.
> 
> It is clear that the CA is not installed. I get errors in 
> /var/log/httpd/error_log for hosts requesting certs, and getting NotFound.
> ipa: INFO: [xmlserver] host/x@DOMAIN: cert_request(u'MIIDnzCCaoc...
> 
> 
> I then removed and uninstalled the other master, which did not have a CA, 
> thinking it could get going with a reinstall. However, the installation fails
> 
> ipa : ERROR  Cannot issue certificates: a CA is not installed. Use 
> the --http-cert-file, --dirsrv-cert-file options to provide custom 
> certificates.
> 
> (there may be some typos in the error messages, since I'm copying from an 
> air-gapped network)
> 
> Is there any way I can manually resurrect the CA? I have the files left over 
> on the original (version 3) master, but did do an uninstall. If that's not 
> possible, is there any way to migrate the users to a new domain with exactly 
> the same name (this would be less convenient, if it's actually possible, 
> since I have to re-enroll all the clients).
> 
> Thanks,
> Marius Bjørnstad
> 


-- 
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] Users can't login on some systems.

[Jakub Hrozek]

On Fri, May 05, 2017 at 11:58:42AM +, Lakshan Jayasekara wrote:
> Ipa user authentication failure on centos client. Login using a valid account 
> and login success for other ipa client servers. It would be great if you can 
> provide any hind or any modification to overcome the situation.

Things I'd try are:
- make sure the user resolves on the target system
- run ipa hbactest to see if the user should be permitted access
- check /var/log/secure and see what does pam_sss return
- increase debug_level in sssd.conf on the client and see what the sssd debug 
logs yield

-- 
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] Users can't login on some systems.

[Lakshan Jayasekara]

Ipa user authentication failure on centos client. Login using a valid account 
and login success for other ipa client servers. It would be great if you can 
provide any hind or any modification to overcome the situation.


Below is the audit log

type=USER_START msg=audit(1493987877.034:112): pid=2333 uid=0 auid=0 ses=1 
subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:session_open 
grantors=pam_selinux,pam_loginuid,pam_selinux,pam_namespace,pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_lastlog
 acct="root" exe="/usr/sbin/sshd" hostname=192.168.104.2 addr=192.168.104.2 
terminal=ssh res=success'
type=CRYPTO_KEY_USER msg=audit(1493987877.052:113): pid=2344 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=destroy 
kind=server fp=ad:95:6a:ee:f6:9b:39:1c:e1:ea:1d:c4:04:8b:2d:6d direction=? 
spid=2344 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.104.2 
terminal=pts/0 res=success'
type=CRYPTO_KEY_USER msg=audit(1493987877.053:114): pid=2344 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=destroy 
kind=server fp=ec:42:62:ce:a9:56:92:f3:0b:a2:9f:b2:eb:ca:f0:4c direction=? 
spid=2344 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.104.2 
terminal=pts/0 res=success'
type=CRYPTO_KEY_USER msg=audit(1493987877.053:115): pid=2344 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=destroy 
kind=server fp=d2:56:9c:49:db:85:40:df:34:de:78:82:e5:fb:66:4e direction=? 
spid=2344 suid=0  exe="/usr/sbin/sshd" hostname=? addr=192.168.104.2 
terminal=pts/0 res=success'
type=USER_LOGIN msg=audit(1493987877.057:116): pid=2344 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login id=0 
exe="/usr/sbin/sshd" hostname=192.168.104.2 addr=192.168.104.2 
terminal=/dev/pts/0 res=success'
type=USER_START msg=audit(1493987877.057:117): pid=2344 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login id=0 
exe="/usr/sbin/sshd" hostname=192.168.104.2 addr=192.168.104.2 
terminal=/dev/pts/0 res=success'
type=CRED_REFR msg=audit(1493987877.063:118): pid=2344 uid=0 auid=0 ses=1 
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred 
grantors=pam_env,pam_localuser,pam_unix acct="root" exe="/usr/sbin/sshd" 
hostname=192.168.104.2 addr=192.168.104.2 terminal=ssh res=success'
type=CRYPTO_KEY_USER msg=audit(1493987950.855:119): pid=2367 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=destroy kind=server fp=ad:95:6a:ee:f6:9b:39:1c:e1:ea:1d:c4:04:8b:2d:6d 
direction=? spid=2367 suid=0  exe="/usr/sbin/sshd" hostname=? 
addr=192.168.104.2 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1493987950.855:120): pid=2367 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=destroy kind=server fp=ec:42:62:ce:a9:56:92:f3:0b:a2:9f:b2:eb:ca:f0:4c 
direction=? spid=2367 suid=0  exe="/usr/sbin/sshd" hostname=? 
addr=192.168.104.2 terminal=? res=success'
type=CRYPTO_KEY_USER msg=audit(1493987950.856:121): pid=2367 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=destroy kind=server fp=d2:56:9c:49:db:85:40:df:34:de:78:82:e5:fb:66:4e 
direction=? spid=2367 suid=0  exe="/usr/sbin/sshd" hostname=? 
addr=192.168.104.2 terminal=? res=success'
type=CRYPTO_SESSION msg=audit(1493987950.859:122): pid=2366 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=start direction=from-server cipher=aes256-ctr ksize=256 mac=hmac-sha1 
pfs=diffie-hellman-group-exchange-sha256 spid=2367 suid=74 rport=50587 
laddr=192.168.220.5 lport=22  exe="/usr/sbin/sshd" hostname=? 
addr=192.168.104.2 terminal=? res=success'
type=CRYPTO_SESSION msg=audit(1493987950.859:123): pid=2366 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=start direction=from-client cipher=aes256-ctr ksize=256 mac=hmac-sha1 
pfs=diffie-hellman-group-exchange-sha256 spid=2367 suid=74 rport=50587 
laddr=192.168.220.5 lport=22  exe="/usr/sbin/sshd" hostname=? 
addr=192.168.104.2 terminal=? res=success'
type=USER_AUTH msg=audit(1493988003.357:124): pid=2369 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=PAM:authentication grantors=? acct="lakshan_864" exe="/usr/sbin/sshd" 
hostname=192.168.104.2 addr=192.168.104.2 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1493988003.360:125): pid=2366 uid=0 auid=4294967295 
ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=challenge-response acct="lakshan_864" exe="/usr/sbin/sshd" hostname=? 
addr=192.168.104.2 terminal=ssh res=failed'
type=CRYPTO_KEY_USER msg=audit(1493988025.470:126): pid=2376 uid=0 
auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 
msg='op=destroy kind=server fp=ad:95:6a:ee:f6:9b:39:1c:e1:ea:1d:c4:04:8b:2d:6d 
direction=? s

[Freeipa-users] Permission Denied for IPA User

[Lakshan Jayasekara]

IPA user cannot login to the target centos system using the ssh. User and the 
password are valid and can access IPA server.


Lakshanth Chandika Jayasekara

[cid:image001.png@01D1F258.46575F30]

Senior Systems Engineer

Mobile:+94 77 294 0396 |  Dir:+94 11 235 6949

General:+94 11 235 6900  Ext: 949 | Fax:+94 11 2544346

LankaClear (Pvt) Ltd, Level 18, Bank of Ceylon Head Office,

"BOC Square", No. 01, Bank of Ceylon Mw, Colombo 01, Sri Lanka.

http://www.lankaclear.com


Confidentiality Notice: The information contained in this message is privileged 
and confidential information intended only for the use of the individual or 
entity named above. If the reader of this message is not the intended 
recipient, or the employee or agent responsible to deliver it to the intended 
recipient, you are hereby notified that any release, dissemination, 
distribution, or copying of this communication is strictly prohibited. If you 
have received this communication in error, please notify the author immediately 
by replying to this message and delete the original message. Internet 
communications cannot be guaranteed to be timely, secure, error or virus-free. 
The sender does not accept liability for any errors or omissions. This email 
has been scanned for all viruses by the Symantec End Point Protection Email 
Security System.
P Save a tree. Don't print this e-mail unless it's really necessary.

-- 
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] Kerberos clients, service tickets, and client to KDC interaction

[Christopher Lamb]

Hi Simo

Thanks, I was hoping you would throw your hat in the ring!

The background to the question, is that I have a throwaway Python Kerberos
Client using the GSS-API that caches service tickets, an a non-throwaway
Java Kerberos Client, also using the GSS-API that does not (yet) cache
service tickets. This implies the Java Client could be hammering the KDC
with requests. I should now be able to confirm this with
/var/log/krb5kdc.log on my KDC.

On the issue of the Java Client  non-caching service tickets I posted a
Stack Overflow question last night.

http://stackoverflow.com/questions/43786908/java-gss-api-service-ticket-not-saved-in-credentials-cache-using-java

thanks

Chris



From:   Simo Sorce 
To: Christopher Lamb/Switzerland/IBM@IBMCH,
freeipa-users@redhat.com
Date:   05/05/2017 11:40
Subject:Re: [Freeipa-users] Kerberos clients, service tickets, and
client to KDC interaction



On Thu, 2017-05-04 at 18:02 +0200, Christopher Lamb wrote:
> Hi All
>
> Is the following statement correct?
>
> "If a kerberos client (e.g. a FreeIPA client) holds a service ticket
> to a service principal in its credentials cache, it no longer needs
> to interact with the KDC to access the service (assuming the ticket
> is still valid). i.e. if a kerberos client is not caching service
> tickets, each interaction with the service principal will require
> getting a new ticket from the KDC."

Yes this statement is correct.

> Are there logs on my FreeIPA-Server I can use to track ticket
> requests from clients, and prove or disprove my statement above?

On each KDC you can check /var/log/krb5kdc.log which contains a log of
all requests received, if you have multiple IPa servers, you may need
to collect all server's logs to see a complete picture as a service may
request a ticket from any of the KDCs (although normally an ipa client
sticks to the same KDC via a locator plugin for libkrb5 and only falls
back to other KDCs if the preferred KDC is unreachable).

Simo.



-- 
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] Kerberos clients, service tickets, and client to KDC interaction

[Simo Sorce]

On Thu, 2017-05-04 at 18:02 +0200, Christopher Lamb wrote:
> Hi All
> 
> Is the following statement correct?
> 
> "If a kerberos client (e.g. a FreeIPA client) holds a service ticket
> to a service principal in its credentials cache, it no longer needs
> to interact with the KDC to access the service (assuming the ticket
> is still valid). i.e. if a kerberos client is not caching service
> tickets, each interaction with the service principal will require
> getting a new ticket from the KDC."

Yes this statement is correct.

> Are there logs on my FreeIPA-Server I can use to track ticket
> requests from clients, and prove or disprove my statement above?

On each KDC you can check /var/log/krb5kdc.log which contains a log of
all requests received, if you have multiple IPa servers, you may need
to collect all server's logs to see a complete picture as a service may
request a ticket from any of the KDCs (although normally an ipa client
sticks to the same KDC via a locator plugin for libkrb5 and only falls
back to other KDCs if the preferred KDC is unreachable).

Simo.

-- 
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] Openwrt-Freeradius-FreeIPA

[Johan Vermeulen]

Hello All,

We have FreeIPA running on Centos7
[root@freeipa03 ~]# cat /etc/*release
CentOS Linux release 7.2.1511 (Core)

Not fully updated but that is planned.

[root@freeipa03 ~]# yum list installed | grep ipa
ipa-admintools.x86_64 4.2.0-15.0.1.el7.centos.19
@updates
ipa-client.x86_64 4.2.0-15.0.1.el7.centos.19
@updates
ipa-python.x86_64 4.2.0-15.0.1.el7.centos.19
@updates
ipa-server.x86_64 4.2.0-15.0.1.el7.centos.19
@updates
ipa-server-dns.x86_64 4.2.0-15.0.1.el7.centos.19
@updates
libipa_hbac.x86_641.13.0-40.el7_2.12
@updates
python-iniparse.noarch0.4-9.el7
@anaconda
python-libipa_hbac.x86_64 1.13.0-40.el7_2.12
@updates
sssd-ipa.x86_64   1.13.0-40.el7_2.12
@updates

We are using FreeIPA to authenticate laptops/users, that works great. Thank
you for making that possible!

Now I bought some Linksys access points and installed Openwrt on them.
Next I'm following the second part of this wiki:

https://www.freeipa.org/page/Using_FreeIPA_and_FreeRadius_as_a_RADIUS_based_software_token_OTP_system_with_CentOS/RedHat_7

starting from : install, configure and test RADIUS server as a frontend to
IPA.

That works great, up to the point where I can do the radtest:

[root@freeipa03 ~]# radtest test password123 192.168.250.12 1812 testing1234
Sending Access-Request Id 26 from 0.0.0.0:44889 to 192.168.250.12:1812
User-Name = 'test'
User-Password = 'password123'
NAS-IP-Address = 192.168.250.12
NAS-Port = 1812
Message-Authenticator = 0x00
Received Access-Accept Id 26 from 192.168.250.12:1812 to
192.168.250.12:44889 length 20

where user test  is in freeipa and 192.168.250.12 is the vpn address of the
ipa server.

My question now is: is it possible to have users connect with the
Linksys/Openwrt access point using username/password from FreeIPA?
So far I'm not getting past EM:

Error: Ignoring request to auth address * port 1812 as server default from
unknown client 10.10.20.117 port 55421 proto udp

where 10.10.20.117 is the Openwrt access point.

I added the access point to /etc/radddb/client.conf in a number of ways,
but nothing changes. Now I'm thinking, because Freeradius now reads from
FreeIPA,
it doesn't recognize the access point.

Thanks for any advise.

greetings, J.
-- 
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] GSSAPI authentication from trusted AD domain

[Sumit Bose]

On Wed, May 03, 2017 at 11:28:18AM +0200, Tiemen Ruiten wrote:
> Tickets on the FreeIPA host after connecting (with a password):
> 
> [adm.tie...@clients.rdmedia.com@neodymium ~]$ klist
> Ticket cache: KEYRING:persistent:998801112:krb_ccache_ZzERoB1
> Default principal: adm.tie...@clients.rdmedia.com
> 
> Valid starting   Expires  Service principal
> 05/03/2017 11:26:03  05/03/2017 21:26:03  krbtgt/
> clients.rdmedia@clients.rdmedia.com
> renew until 05/04/2017 11:26:03
> 
> 
> 
> Tickets on the AD laptop after a connection attempt:
> 
> C:\Users\adm.tiemen.CLIENTS>klist
> 
> Current LogonId is 0:0x587aa
> 
> Cached Tickets: (2)
> 
> #0> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM
> Server: krbtgt/CLIENTS.RDMEDIA.COM @ CLIENTS.RDMEDIA.COM
> KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
> Ticket Flags 0x40e1 -> forwardable renewable initial
> pre_authent name_canonicalize
> Start Time: 5/3/2017 11:12:46 (local)
> End Time:   5/3/2017 21:12:46 (local)
> Renew Time: 5/10/2017 11:12:46 (local)
> Session Key Type: AES-256-CTS-HMAC-SHA1-96
> Cache Flags: 0x1 -> PRIMARY
> Kdc Called: vm-win-01.clients.rdmedia.com
> 
> #1> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM
> Server: LDAP/vm-win-01.clients.rdmedia.com/clients.rdmedia.com @
> CLIENTS.RDMEDIA.COM
> KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
> Ticket Flags 0x40a5 -> forwardable renewable pre_authent
> ok_as_delegate name_canonicalize
> Start Time: 5/3/2017 11:12:46 (local)
> End Time:   5/3/2017 21:12:46 (local)
> Renew Time: 5/10/2017 11:12:46 (local)
> Session Key Type: AES-256-CTS-HMAC-SHA1-96
> Cache Flags: 0
> Kdc Called: vm-win-01.clients.rdmedia.com

There is no ticket for
host/neodymium.test.ams.i.rdmedia@test.ams.i.rdmedia.com
nor a cross-realm ticket
krbtgt/test.ams.i.rdmedia@clients.rdmedia.com

So it looks the ssh client in the Windows host didn't try to get a
Kerberos ticket for the IPA client. Did you use the FQDN
neodymium.test.ams.i.rdmedia.com when trying to connect to the IPA
client?

According to the logs it looks like you are using kitty, have you tried
to use putty?

bye,
Sumit

> 
> 
> 
> 
> On 2 May 2017 at 19:45, Tiemen Ruiten  wrote:
> 
> > It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need
> > for mapping. However on the AD host:
> >
> > Microsoft Windows [Version 6.3.9600]
> >
> > (c) 2013 Microsoft Corporation. All rights reserved.
> >
> >
> > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist
> >
> >
> > Current LogonId is 0:0x603b58
> >
> >
> > Cached Tickets: (0)
> >
> >
> > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>
> >
> > Note that this is the domain controller and I'm logged in using the
> > experimental Win32-OpenSSH server. Not sure if that makes a difference. I
> > am not currently in the office, so unfortunately can't turn on the only
> > joined laptop in this domain.
> >
> > How can I ensure a proper ticket is generated?
> >
> > On 2 May 2017 at 18:25, Sumit Bose  wrote:
> >
> >> On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote:
> >> > I think I just realised that my expectation may be wrong: GSSAPI login
> >> with
> >> > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it
> >> > correct to also expect passwordless login with an AD user to a FreeIPA
> >> host?
> >>
> >> The AD user case should work as well.
> >>
> >> First please send the SSSD version you use on the IPA client,
> >> alternatively you can check if
> >> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This
> >> would tell if SSSD can map the user name to the Kerberos principal of if
> >> additional configuration is needed.
> >>
> >> On the AD host please check after trying to connect with ssh if there is
> >> a proper service ticket for the IPA client by calling 'klist' in cmd.exe
> >> or PowerShell.
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > On 2 May 2017 at 17:40, Jason B. Nance  wrote:
> >> >
> >> > > Hi Tiemen,
> >> > >
> >> > > To be clear, what I'm trying to do: log in from an AD account
> >> > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA
> >> > > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I
> >> > > expect to be logged in through GSSAPI, instead I get a password
> >> prompt.
> >> > >
> >> > > I'm assuming that you are coming from a Windows client that is domain
> >> > > joined and logged into that Windows client with the same domain
> >> credentials
> >> > > that you are using to connect to the IPA-joined host.  Do you also
> >> have
> >> > > your SSH client configured to attempt GSSAPI?  It appears that you do
> >> from
> >> > > the logs you provided but I'm just double-checking.
> >> > >
> >> > > In my setup I've found that this feature does not work all of the
> >> time.
> >> > > I've not yet been able to track it down a

[Freeipa-users] Need LDAP access for host not in IPA domain

[Detlev Habicht]

Hello,

i need a simple, plain LDAP bind for authentication for a host,
which is not part of my IPA domain.

Something like this is working in the domain:

 ldapsearch -vx -H ldaps://xxx.yyy.intern -b "cn=accounts,dc=yyy,dc=intern"

My problem is, it is only working with the hostname xxx.yyy.intern which
is part of my domain yyy.intern. But outside of the domain i have to
use the IP address or something like xxx.yyy.zzz.de .

But than i have this error message:

ldap_initialize( ldaps://xxx.yyy.zzz.de:636/??base )
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Any idea what i can do?

Thank you!

Detlev

P.S.: I have the same problem in the domain, when i am not using 
  xxx.yyy.intern. IP address for example is also not working.

--
  Detlev  | Institut fuer Mikroelektronische Systeme
  Habicht | D-30167 Hannover +49 511 76219662 habi...@ims.uni-hannover.de
  + Handy+49 172 5415752  ---



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