Re: [Freeipa-users] Account/password expirations

[Prasun Gera]

>
> Your can still authenticate with SSH keys, but to access any NFS 4 shares
> they will need a Kerberos ticket, which can be obtained via a 'kinit' after
> logging in.
>

Then how does the key authentication work if the .ssh directory on nfs4 is
not accessible ?  Doesn't the key authentication process rely on
.ssh/authorized keys being readable by the authentication module ?
-- 
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 vulnerability management SSL

[Sean Hogan]

Hi Noriko,

  Thanks for the suggestions,

  I had to trim out the GCM ciphers in order to get IPA to start back up or
I would get the unknown cipher message

Nmap is still showing the same 13 ciphers as before though like nothing had
changed and I did ipactl stop, made modification, ipactl start

tarting Nmap 5.51 ( http://nmap.org ) at 2016-04-28 18:44 EDT
Nmap scan report for
Host is up (0.53s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2
| Ciphers (13)
|   SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
|   SSL_RSA_FIPS_WITH_DES_CBC_SHA
|   TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
|   TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
|   TLS_RSA_WITH_3DES_EDE_CBC_SHA
|   TLS_RSA_WITH_AES_128_CBC_SHA
|   TLS_RSA_WITH_AES_128_CBC_SHA256
|   TLS_RSA_WITH_AES_128_GCM_SHA256
|   TLS_RSA_WITH_AES_256_CBC_SHA
|   TLS_RSA_WITH_AES_256_CBC_SHA256
|   TLS_RSA_WITH_DES_CBC_SHA
|   TLS_RSA_WITH_RC4_128_MD5
|   TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
|_  uncompressed

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

Current Config:

dse.ldif
dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off
nsSSL3: off
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20150420131850Z
modifyTimestamp: 20150420131906Z
nsSSL3Ciphers:
-rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_

rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha,+tls_rsa_aes_128_sha

,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_
 aes_256_sha,+rsa_aes_256_sha
numSubordinates: 1


nss.conf
# SSL 3 ciphers. SSL 2 is disabled by default.
NSSCipherSuite
-rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha,+tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha,+tls_rsa_aes_128_gcm_sha,+tls_dhe_rsa_aes_128_gcm_sha,+tls_dhe_dss_aes_128_gcm_sha

NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2


Does nss.conf have anything to do with the dir srv ciphers?  I know the 389
docs says they are tied together so the way I have been looking at it is
nss.conf lists the allowed ciphers where dse.ldif lists which ones to use
for 389 from nss.conf.  Is that correct?  Is there any other place where
ciphers would be ignored?

nss-3.19.1-8.el6_7.x86_64
sssd-ipa-1.12.4-47.el6_7.4.x86_64
ipa-client-3.0.0-47.el6_7.1.x86_64
ipa-server-selinux-3.0.0-47.el6_7.1.x86_64
ipa-pki-common-theme-9.0.3-7.el6.noarch
ipa-python-3.0.0-47.el6_7.1.x86_64
ipa-server-3.0.0-47.el6_7.1.x86_64
libipa_hbac-python-1.12.4-47.el6_7.4.x86_64
ipa-admintools-3.0.0-47.el6_7.1.x86_64
ipa-pki-ca-theme-9.0.3-7.el6.noarch
389-ds-base-1.2.11.15-68.el6_7.x86_64
389-ds-base-libs-1.2.11.15-68.el6_7.x86_64


I need to get rid of any rc4s

Sean Hogan
Security Engineer
Watson Security & Risk Assurance
Watson Cloud Technology and Support
email: scho...@us.ibm.com | Tel 919 486 1397









From:   Noriko Hosoi 
To: Ludwig Krispenz , freeipa-users@redhat.com
Date:   04/28/2016 12:08 PM
Subject:Re: [Freeipa-users] IPA vulnerability management SSL
Sent by:freeipa-users-boun...@redhat.com



Thank you for including me in the loop, Ludwig.

On 04/28/2016 04:34 AM, Ludwig Krispenz wrote:
> If I remember correctly we did the change in default ciphers and the
option for handling in 389-ds > 1.3.3, so it would not be in RHEL6, adding
Noriko to get confirmation.

Ludwig is right.  The way how to set nsSSL3Ciphers has been changed since
1.3.3 which is available on RHEL-7.

This is one of the newly supported values of nsSSL3Ciphers:
  Notes: if the value contains +all, then - is removed from the
  list.
  
http://www.port389.org/docs/389ds/design/nss-cipher-design.html#available-by-setting-allnss-3162-1
On the older 389-ds-base including 389-ds-base-1.2.11.X on RHEL-6.X, if
"+all" is found in the value, all the available ciphers are enabled.

To workaround it, could you try explicitely setting ciphers as follows?
nsSSL3Ciphers:
-rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha,


+tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha,


+tls_rsa_aes_128_gcm_sha,+tls_dhe_rsa_aes_128_gcm_sha,+tls_dhe_dss_aes_128_gcm_sha


Thanks,
--noriko

On 04/28/2016 04:34 AM, Ludwig Krispenz wrote:
  wanted to add Noriko, but hit send to quickly

  On 04/28/2016 01:26 PM, Ludwig Krispenz wrote:

On 04/28/2016 12:06 PM, Martin Kosek wrote:
  On 04/28/2016 01:23 AM, Sean Hogan wrote:
Hi Martin,

No joy on placing - in front of the RC4s


I modified my nss.conf to now 

Re: [Freeipa-users] ipa-client password authentication failed

[siology.io]

On a clean centos 7 VM, after installation of ipa-server browsing to the
ipa web UI gets me in the httpd error_logs:

[Thu Apr 28 18:41:11.826134 2016] [:error] [pid 10162] [remote 10.0.4.10:244]
mod_wsgi (pid=10162): Target WSGI script '/usr/share/ipa/wsgi/plugins.py'
does not contain WSGI application 'application'.

Is this a known issue ? I didn't get much out of google.
-- 
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] Account/password expirations

[Anon Lister]

Your can still authenticate with SSH keys, but to access any NFS 4 shares
they will need a Kerberos ticket, which can be obtained via a 'kinit' after
logging in. I forget what the default timeout is but they do expire, and at
that point access to those shares (by a user or process acting as that
user) will not be allowed. You may increase the timeout to something
comfortable. We have a solution where we have tickets set at a day and a
login script prompts for the password ( actually just runs kint ) for the
user if their ticket is expired, which covers interactive login, however it
does break scp unless they login first. For us it hasn't come up enough to
warrent coming up with another solution.

Note this is for sec=krb*, you can do nfs4 sec=sys and get no extra
security but other features of v4, and mount as normal.

-Anon
On Apr 28, 2016 5:09 PM, "Prasun Gera"  wrote:

>
>
>> Moreover, if you login through an SSH key, you don't get a ticket on
>> login and you can't kinit, so you can't access any network resources
>> anyway..
>>
>>
> A bit off topic, but a related question:
> How does nfsv4 work with ssh keys ? Does it mean that you can't use ssh
> keys if /home is nfsv4 mounted ? I had tried nfsv4 briefly, but had some
> issues, and didn't look it in too much detail. Also, is it possible to use
> nfsv4 home in an HPC cluster environment where something like torque or
> slurm schedules jobs ? For nfsv3, I suppose the workload manager runs as
> the user, and hence it can read/write to the user's directory. Would it
> still be possible to do that in an nfsv4 system ? How would renewals happen
> for long running jobs without any user interaction ?
>
>
>
>
> --
> 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

[Freeipa-users] FreeIPA with smart card using LightDM

[Michael Rainey (Contractor)]

I am wondering if anyone out there is currently using freeIPA with smart 
cards along with LightDM.  I have systems running SL7.2 with GDM and I 
have users that prefer to use XFCE or KDE over the default GNOME-Shell.  
The problem with GDM is I am not able to get screen lock feature to work 
across multiple desktop environments.  If anyone uses XFCE, xscreensaver 
will need to be installed so they can lock their screen.  This choice 
also makes using the smart card useless when logging back into the 
system.  Also, I haven't been able call the lock screen from the 
command-line.  What examples I have found do not work due to a missing 
ScreenSaver object.


If anyone has any good solutions to this problem I would enjoy hearing them.

Thanks in advance.
--
*Michael Rainey*
-- 
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] Account/password expirations

[Prasun Gera]

>
> Moreover, if you login through an SSH key, you don't get a ticket on
> login and you can't kinit, so you can't access any network resources
> anyway..
>
>
A bit off topic, but a related question:
How does nfsv4 work with ssh keys ? Does it mean that you can't use ssh
keys if /home is nfsv4 mounted ? I had tried nfsv4 briefly, but had some
issues, and didn't look it in too much detail. Also, is it possible to use
nfsv4 home in an HPC cluster environment where something like torque or
slurm schedules jobs ? For nfsv3, I suppose the workload manager runs as
the user, and hence it can read/write to the user's directory. Would it
still be possible to do that in an nfsv4 system ? How would renewals happen
for long running jobs without any user interaction ?
-- 
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] HBAC implementation help

[Ben .T.George]

Hi List,

i have a working setup of IPA with AD integrated and one client joined.

i want to implement HBAC rules against this client. can anyone please share
me good articles of implementing HBAC from web UI.


Thanks & Regards,
Ben
-- 
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] Account/password expirations

[Steve Huston]

Unfortunately I've been swapping tasks enough that I keep forgetting
where I left off here.  But I'm pretty sure the problem was that sssd
would stop a user who was disabled (as you mention) but not if they
were expired, either the account itself with krbPrincipalExpiration or
the password with krbPasswordExpiration.  I know that one does not get
a ticket automatically if using ssh public key authentication, which
is fine, but there's a specific mention in the link I referenced
(https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-pwd-expiry.html)
that basically if you do this, then sssd will consult for password
expiration and warn the user accordingly.  That's what I need to
happen, and would like it to be native IPA-ish calls, rather than LDAP
which is what I need to set it to if I want that functionality (which
then also causes other problems, such as losing HBAC and having to set
a filter I've yet to get right to allow users to login to anything).

So if there's a chance of swinging the vote the other way, I'll keep
beating my drum :D

On Thu, Apr 21, 2016 at 3:37 PM, Jakub Hrozek  wrote:
> On Thu, Apr 21, 2016 at 01:26:19PM -0400, Steve Huston wrote:
>> On Tue, Apr 19, 2016 at 11:57 AM, Jakub Hrozek  wrote:
>> > Did you test that this actually fails with id_provider=ipa? I would
>> > assume the IPA KDC would kick you out and prompt for a new password..
>>
>> If you're using a password, yes it kicks back and requires you to
>> change it.  The problem is if you're not using a password to
>> authenticate, but instead using an SSH key, then it appears there's no
>> hooks to check with IPA if the password (or the principal itself) is
>> expired and the user is allowed to continue to login.  The
>> "recommended" way to do this in RHEL6 is to set access_provider to
>> ldap in sssd, but that doesn't seem to cover all cases and doesn't
>> play well with other IPA things (like HBAC) from what I can tell.
>
> Then in my opinion SSSD is behaving correctly there. It wouldn't let in
> a locked user (it would check the nsaccountlock attribute), but I'm not
> sure it would be correct to check krbPasswordExpiration if you're using
> a completely different method to authenticate..
>
> Moreover, if you login through an SSH key, you don't get a ticket on
> login and you can't kinit, so you can't access any network resources
> anyway..
>
> But to be honest, this is something we discussed even among IPA
> developers and we're not in total agreement here either, so maybe others
> will overrule me :)
>
> --
> 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



-- 
Steve Huston - W2SRH - Unix Sysadmin, PICSciE/CSES & Astrophysical Sci
  Princeton University  |ICBM Address: 40.346344   -74.652242
345 Lewis Library   |"On my ship, the Rocinante, wheeling through
  Princeton, NJ   08544 | the galaxies; headed for the heart of Cygnus,
(267) 793-0852  | headlong into mystery."  -Rush, 'Cygnus X-1'

-- 
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] Free IPA Client in Docker

[Hosakote Nagesh, Pawan]

Hi,
  I am planning to deploy FreeIPA Client in a docker where my Apps are 
running. However I hit a road block as there seems to be problem with the 
docker’s hostname settings
In DNS records.

Debug Log
———

ipa-client-install --hostname=`hostname -f` --mkhomedir -N --force-join —debug

.

.

.

.

debug

zone phx01.eaz.ebayc3.com.

update delete . IN A

show

send

update add . 1200 IN A 172.17.0.3

show

send


Starting external process

args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt

Process execution failed

Traceback (most recent call last):

  File "/usr/sbin/ipa-client-install", line 2603, in 

sys.exit(main())

  File "/usr/sbin/ipa-client-install", line 2584, in main

rval = install(options, env, fstore, statestore)

  File "/usr/sbin/ipa-client-install", line 2387, in install

client_dns(cli_server[0], hostname, options.dns_updates)

  File "/usr/sbin/ipa-client-install", line 1423, in client_dns

update_dns(server, hostname)

  File "/usr/sbin/ipa-client-install", line 1410, in update_dns

if do_nsupdate(update_txt):

  File "/usr/sbin/ipa-client-install", line 1346, in do_nsupdate

ipautil.run(['/usr/bin/nsupdate', '-g', UPDATE_FILE])

  File "/usr/lib/python2.7/dist-packages/ipapython/ipautil.py", line 303, in run

close_fds=True, env=env, cwd=cwd)

  File "/usr/lib/python2.7/subprocess.py", line 710, in __init__

errread, errwrite)

  File "/usr/lib/python2.7/subprocess.py", line 1327, in _execute_child

raise child_exception

OSError: [Errno 2] No such file or directory


As a Follow up question I also wanted to know why is absolutely necessary for 
Kerberos Client to have hostname? Wont Client initiate the connection and 
FreeIPA server can take it from there.
If so what is the need of FQDN for FreeIPA client at all?

-
Best,
Pawan
-- 
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 vulnerability management SSL

[Noriko Hosoi]

Thank you for including me in the loop, Ludwig.

On 04/28/2016 04:34 AM, Ludwig Krispenz wrote:
> If I remember correctly we did the change in default ciphers and the 
option for handling in 389-ds > 1.3.3, so it would not be in RHEL6, 
adding Noriko to get confirmation.


Ludwig is right.  The way how to set nsSSL3Ciphers has been changed 
since 1.3.3 which is available on RHEL-7.


This is one of the newly supported values of nsSSL3Ciphers:

   Notes: if the value contains +all, then *-* is removed from
   the list.
   
http://www.port389.org/docs/389ds/design/nss-cipher-design.html#available-by-setting-allnss-3162-1

On the older 389-ds-base including 389-ds-base-1.2.11.X on RHEL-6.X, if 
"+all" is found in the value, all the available ciphers are enabled.


To workaround it, could you try explicitely setting ciphers as follows?
nsSSL3Ciphers: 
-rsa_null_md5,-rsa_null_sha,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4_56_sha,-tls_dhe_dss_1024_rc4_sha,

 
+tls_rsa_aes_128_sha,+rsa_aes_128_sha,+tls_dhe_dss_aes_128_sha,+tls_dhe_rsa_aes_128_sha,+tls_rsa_aes_256_sha,+rsa_aes_256_sha,
 
+tls_rsa_aes_128_gcm_sha,+tls_dhe_rsa_aes_128_gcm_sha,+tls_dhe_dss_aes_128_gcm_sha

Thanks,
--noriko

On 04/28/2016 04:34 AM, Ludwig Krispenz wrote:

wanted to add Noriko, but hit send to quickly

On 04/28/2016 01:26 PM, Ludwig Krispenz wrote:


On 04/28/2016 12:06 PM, Martin Kosek wrote:

On 04/28/2016 01:23 AM, Sean Hogan wrote:

Hi Martin,

No joy on placing - in front of the RC4s


I modified my nss.conf to now read
# SSL 3 ciphers. SSL 2 is disabled by default.
NSSCipherSuite
+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha 



# SSL Protocol:
# Cryptographic protocols that provide communication security.
# NSS handles the specified protocols as "ranges", and automatically
# negotiates the use of the strongest protocol for a connection 
starting
# with the maximum specified protocol and downgrading as necessary 
to the

# minimum specified protocol that can be used between two processes.
# Since all protocol ranges are completely inclusive, and no 
protocol in the

NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

dse.ldif

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off
nsSSL3: off
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20150420131850Z
modifyTimestamp: 20150420131906Z
nsSSL3Ciphers: 
+all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4

_56_sha,-tls_dhe_dss_1024_rc4_sha
numSubordinates: 1



But I still get this with nmap.. I thought the above would remove
-tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the 
fact that I am not
offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really 
understanding
where it is coming from cept the +all from DS but the - should be 
negating that?


Starting Nmap 5.51 ( http://nmap.org  ) at 
2016-04-27 17:37 EDT

Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
Host is up (0.86s latency).
PORT STATE SERVICE
636/tcp open ldapssl
| ssl-enum-ciphers:
| TLSv1.2
| Ciphers (13)
| SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
| SSL_RSA_FIPS_WITH_DES_CBC_SHA
| TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
| TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA256
| TLS_RSA_WITH_AES_128_GCM_SHA256
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA256
| TLS_RSA_WITH_DES_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
|_ uncompressed

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds



It seems no matter what config I put into nss.conf or dse.ldif 
nothing changes
with my nmap results. Is there supposed to be a be a section to add 
TLS ciphers

instead of SSL

Not sure now, CCing Ludwig who was involved in the original RHEL-6
implementation.
If I remember correctly we did the change in default ciphers and the 
option for handling in 389-ds > 1.3.3, so it would not be in RHEL6, 
adding Noriko to get confirmation.


but the below comments about changing ciphers in dse.ldif could help 
in using the "old" way to set ciphers

Just to be sure, when you are modifying dse.ldif, the procedure
should be always following:

1) Stop Directory Server service
2) Modify dse.ldif
3) Start Directory Server service

Otherwise it won't get applied and will get overwritten later.

In any case, the ciphers with RHEL-6 should be secure enough, the 
ones in
FreeIPA 4.3.1 should be even better. This is for example an nmap 
taken on

FreeIPA Demo instance that runs on FreeIPA 4.3.1:

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 7.12 ( https://nmap.org ) at 201

Re: [Freeipa-users] Quick question regarding modifying attributes

[Sullivan, Daniel [AAA]]

Jakub,

Thank you for your reply.  I did not know that the compat tree was populated 
from sssd; Do you have any experience and or recommendation on using the 
full_name_format variable of sssd.conf to manipulate how cn’s are populated in 
anchor records?  Basically I’m interested in trying to get IPA to provision 
anchor records for a trusted domain without the @f.d.q.n appended to usernames. 
 It seems like having a custom full_name_format (sssd.conf) possibly in 
conjunction with default_domain_suffix (sssd.conf) might achieve this (have 
already done some internal testing with partial results, running into some 
issues but interested in yours and the groups opinion on the viability of this).

I appreciate your help.

Best,

Dan

> On Apr 28, 2016, at 11:29 AM, Jakub Hrozek  wrote:
> 
> On Wed, Apr 27, 2016 at 06:58:35PM +, Sullivan, Daniel [AAA] wrote:
>> Hi,
>> 
>> I have a trusted AD domain that I am enumerating object via IPA.  I wanted 
>> to know if i should be able to manipulate the uidNumber and gidNumber stored 
>> in the default ID view via by using the ldapmodify command, for example, for 
>> this DN (not local):
>> 
>> uid=u...@domain.edu,cn=users,cn=compat,dc=ipatst,dc=cri,dc=uchicago,dc=edu
> 
> The compat tree is autogenerated and can't be modified.
> 
> If you want ID views to be applicable to clients using the compat tree,
> you can define the overrides using the standard IPA CLI tools in the
> "default Trust View", because that one is applied on the server itself
> and the compat tree is autogenerated from the data that SSSD on the
> server delivers.
> 
> -- 
> 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



This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


-- 
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 server having cert issues

[Bret Wortman]

Okay, I ran 'ldapsearch -x -h zsipa -p 389 -b 'ou=people,o=ipaca' and 
dumped that to a file. I'm still not clear on what I'm supposed to be 
looking for in the output, though.


The result of systemctl | grep dirsrv@ was pretty uninformative. If the 
answer was "dirsrv", then I don't find that in the ldapsearch results. 
Assuming that was the ldapsearch command I needed to run


On 04/28/2016 12:04 PM, Petr Vobornik wrote:

On 04/28/2016 05:49 PM, Bret Wortman wrote:

My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
have the pki-server binary itself. Will reinstalling this rpm hurt me in
any way? Without it, I'm not sure how to check my system against the
messages you provided below.

Not sure what you mean. Running doesn't require any additional packages.
It is just to get additional logs.
   systemctl status  pki-tomcatd@pki-tomcat.service
   journalctl -u pki-tomcatd@pki-tomcat.service

And the links below are about checking if CA users have correctly mapped
certificates in LDAP database in ou=people,o=ipaca for that you need
only ldapsearch command and start directory server:
   systemctl start dirsrv@YOUR-REALM-TEST.service

Proper name for dirsrv@YOUR-REALM-TEST.service can be found using:
   systemctl | grep dirsrv@



On 04/28/2016 11:07 AM, Petr Vobornik wrote:

On 04/28/2016 04:07 PM, Bret Wortman wrote:

Okay. This morning, I turned back time to 4/1 and started up IPA. It
didn't
work, but I got something new and interesting in the debug log, which
I've
posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came
pouring out
which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html


On 04/27/2016 02:24 PM, Bret Wortman wrote:

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
looks
logical to me, but I can't spot anything that looks like a root
cause error.
The selftests are all okay, I think. The debug log might have
something, but
it might also just be complaining about ldap not being up because
it's not.


On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?

I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.

I'd ignore the two unknown certs for now. They look like someone was
experimenting with issuing a cert and didn't quite get things working.

The CA seems to be throwing an error. I'd check the syslog for
messages from
certmonger and look at the CA debug log and selftest log.

rob


[snip]







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

[Freeipa-users] freeipa update changed my cipher set

[Roderick Johnstone]

Hi

RHEL7 running ipa-server-4.2.0-15.el7_2.6.1.x86_64

A couple of months ago I updated /etc/dirsrv/slapd-XXX.XXX.XXX/dse.ldif 
to customise the cipher suite in use by freeipa (see previous thread on 
this list).


When the update to ipa-server-4.2.0-15.el7_2.6.1.x86_64 came in on April 
14 it saved my dse.ldif to dse.ldif.ipa.87160d3fec74fa3f and reverted 
some, but not all of, my changed settings in dse.ldif.


I'd like to understand what is expected to happen to this file on a 
package upgrade (rpm reports that this file is not owned by any package 
so I guess its manipulated by a scriplet) since at least one of my 
changes was preserved.


Also, if I need to maintain a customised cipher suite for ipa, am I 
required to only do yum updates of the ipa-server package by hand and 
manually merge back in my changes, or is there a better way?


Thanks

Roderick Johnstone

--
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 vulnerability management SSL

[Sean Hogan]

Hey guys..  yes I so want to upgrade to 4.x however not in my control right
now and can not really discuss.  I see us stuck at 3.x for a while.



Sean Hogan







From:   Sean Hogan/Durham/IBM
To: Ludwig Krispenz 
Cc: freeipa-users@redhat.com, Noriko Hosoi 
Date:   04/28/2016 08:20 AM
Subject:Re: [Freeipa-users] IPA vulnerability management SSL


Yes sir.. I am stopping DS with ipactl stop before making changes.. .I
often times have to really play with the ciphers cause many times when I
restart DS I get unknown cipher and IPA fails to start.  Go back into
dse.ldif and modify til it comes back up.




Sean Hogan








From:   Ludwig Krispenz 
To: freeipa-users@redhat.com, Noriko Hosoi 
Date:   04/28/2016 04:46 AM
Subject:Re: [Freeipa-users] IPA vulnerability management SSL
Sent by:freeipa-users-boun...@redhat.com



wanted to add Noriko, but hit send to quickly

On 04/28/2016 01:26 PM, Ludwig Krispenz wrote:
>
> On 04/28/2016 12:06 PM, Martin Kosek wrote:
>> On 04/28/2016 01:23 AM, Sean Hogan wrote:
>>> Hi Martin,
>>>
>>> No joy on placing - in front of the RC4s
>>>
>>>
>>> I modified my nss.conf to now read
>>> # SSL 3 ciphers. SSL 2 is disabled by default.
>>> NSSCipherSuite
>>>
+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha

>>>
>>>
>>> # SSL Protocol:
>>> # Cryptographic protocols that provide communication security.
>>> # NSS handles the specified protocols as "ranges", and automatically
>>> # negotiates the use of the strongest protocol for a connection
>>> starting
>>> # with the maximum specified protocol and downgrading as necessary
>>> to the
>>> # minimum specified protocol that can be used between two processes.
>>> # Since all protocol ranges are completely inclusive, and no
>>> protocol in the
>>> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
>>>
>>> dse.ldif
>>>
>>> dn: cn=encryption,cn=config
>>> objectClass: top
>>> objectClass: nsEncryptionConfig
>>> cn: encryption
>>> nsSSLSessionTimeout: 0
>>> nsSSLClientAuth: allowed
>>> nsSSL2: off
>>> nsSSL3: off
>>> creatorsName: cn=server,cn=plugins,cn=config
>>> modifiersName: cn=directory manager
>>> createTimestamp: 20150420131850Z
>>> modifyTimestamp: 20150420131906Z
>>> nsSSL3Ciphers:
>>> +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4
>>> _56_sha,-tls_dhe_dss_1024_rc4_sha
>>> numSubordinates: 1
>>>
>>>
>>>
>>> But I still get this with nmap.. I thought the above would remove
>>> -tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the
>>> fact that I am not
>>> offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really
>>> understanding
>>> where it is coming from cept the +all from DS but the - should be
>>> negating that?
>>>
>>> Starting Nmap 5.51 ( http://nmap.org  ) at
>>> 2016-04-27 17:37 EDT
>>> Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
>>> Host is up (0.86s latency).
>>> PORT STATE SERVICE
>>> 636/tcp open ldapssl
>>> | ssl-enum-ciphers:
>>> | TLSv1.2
>>> | Ciphers (13)
>>> | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
>>> | SSL_RSA_FIPS_WITH_DES_CBC_SHA
>>> | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
>>> | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
>>> | TLS_RSA_WITH_3DES_EDE_CBC_SHA
>>> | TLS_RSA_WITH_AES_128_CBC_SHA
>>> | TLS_RSA_WITH_AES_128_CBC_SHA256
>>> | TLS_RSA_WITH_AES_128_GCM_SHA256
>>> | TLS_RSA_WITH_AES_256_CBC_SHA
>>> | TLS_RSA_WITH_AES_256_CBC_SHA256
>>> | TLS_RSA_WITH_DES_CBC_SHA
>>> | TLS_RSA_WITH_RC4_128_MD5
>>> | TLS_RSA_WITH_RC4_128_SHA
>>> | Compressors (1)
>>> |_ uncompressed
>>>
>>> Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
>>>
>>>
>>>
>>> It seems no matter what config I put into nss.conf or dse.ldif
>>> nothing changes
>>> with my nmap results. Is there supposed to be a be a section to add
>>> TLS ciphers
>>> instead of SSL
>> Not sure now, CCing Ludwig who was involved in the original RHEL-6
>> implementation.
> If I remember correctly we did the change in default ciphers and the
> option for handling in 389-ds > 1.3.3, so it would not be in RHEL6,
> adding Noriko to get confirmation.
>
> but the below comments about changing ciphers in dse.ldif could help
> in using the "old" way to set ciphers
>> Just to be sure, when you are modifying dse.ldif, the procedure
>> should be always following:
>>
>> 1) Stop Directory Server service
>> 2) Modify dse.ldif
>> 3) Start Directory Server service
>>
>> Otherwise it won't get applied and will get overwritten later.
>>
>> In any case, the ciphers with RHEL-6 should be secure enough, the
>> ones in
>> FreeIPA 4.3.1 should be even better. This is for example an nmap
>> taken on
>> FreeIPA Demo instance that runs on FreeIPA 4.3.1:
>>
>> $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org
>>
>> Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-28 12:02 CEST
>> Nmap 

Re: [Freeipa-users] IPA server having cert issues

[Bret Wortman]

Look, I'll be honest. When IPA is in this much of a knot, I don't know 
how to do the simplest things with its various components. For example, 
I've no clue how to search the ldap database for anything. Or even how 
to authenticate since Kerberos isn't running. IPA has sheltered me from 
ldap for so long that it's a problem at times like this.


That being said, here are the things I /was/ able to handle:

Apr 01 11:02:40 zsipa.private.net server[6896]: Java virtual machine 
used: /usr/lib/jvm/jre/bin/java
Apr 01 11:02:40 zsipa.private.net server[6896]: classpath used: 
/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/lib/java/commons-daemon.j
Apr 01 11:02:40 zsipa.private.net server[6896]: main class used: 
org.apache.catalina.startup.Bootstrap
Apr 01 11:02:40 zsipa.private.net server[6896]: flags used: 
-DRESTEASY_LIB=/usr/share/java/resteasy
Apr 01 11:02:40 zsipa.private.net server[6896]: options used: 
-Dcatalina.base=/var/lib/pki/pki-tomcat 
-Dcatalina.home=/usr/share/tomcat -Djava.endorsed.dirs= -Djava.io.

Apr 01 11:02:40 zsipa.private.net server[6896]: arguments used: start
Apr 01 11:02:40 zsipa.private.net server[6896]: Apr 01, 2016 11:02:40 AM 
org.apache.catalina.startup.ClassLoaderFactory validateFile
Apr 01 11:02:40 zsipa.private.net server[6896]: WARNING: Problem with 
JAR file [/var/lib/pki/pki-tomcat/lib/log4j.jar], exists: [false], 
canRead: [false]
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'enableOCSP' to 'false' did not find a matchi
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderURL' to 'http://zsipa.private.net:9
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspResponderCertNickname' to 'ocspSigningCe
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspCacheSize' to '1000' did not find a matc
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMinCacheEntryDuration' to '60' did not f
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspMaxCacheEntryDuration' to '120' did not
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ocspTimeout' to '10' did not find a matching
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'strictCiphers' to 'true' did not find a matc
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'sslOptions' to 'ssl2=true,ssl3=true,tls=true
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ssl2Ciphers' to '-SSL2_RC4_128_WITH_MD5,-SSL
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'ssl3Ciphers' to '-SSL3_FORTEZZA_DMS_WITH_NUL
Apr 01 11:02:41 zsipa.private.net server[6896]: Apr 01, 2016 11:02:41 AM 
org.apache.catalina.startup.SetAllPropertiesRule begin
Apr 01 11:02:41 zsipa.private.net server[6896]: WARNING: 
[SetAllPropertiesRule]{Server/Service/Connector} Setting property 
'tlsCiphers' to '-TLS_

Re: [Freeipa-users] Quick question regarding modifying attributes

[Jakub Hrozek]

On Wed, Apr 27, 2016 at 06:58:35PM +, Sullivan, Daniel [AAA] wrote:
> Hi,
> 
> I have a trusted AD domain that I am enumerating object via IPA.  I wanted to 
> know if i should be able to manipulate the uidNumber and gidNumber stored in 
> the default ID view via by using the ldapmodify command, for example, for 
> this DN (not local):
> 
> uid=u...@domain.edu,cn=users,cn=compat,dc=ipatst,dc=cri,dc=uchicago,dc=edu

The compat tree is autogenerated and can't be modified.

If you want ID views to be applicable to clients using the compat tree,
you can define the overrides using the standard IPA CLI tools in the
"default Trust View", because that one is applied on the server itself
and the compat tree is autogenerated from the data that SSSD on the
server delivers.

-- 
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 server having cert issues

[Bret Wortman]

Okay. I got hung up on the first link doing some checking using 
pki-server. I don't see any reference to ldapsearch in either message, 
but I'll do what I can.



On 04/28/2016 12:04 PM, Petr Vobornik wrote:

On 04/28/2016 05:49 PM, Bret Wortman wrote:

My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
have the pki-server binary itself. Will reinstalling this rpm hurt me in
any way? Without it, I'm not sure how to check my system against the
messages you provided below.

Not sure what you mean. Running doesn't require any additional packages.
It is just to get additional logs.
   systemctl status  pki-tomcatd@pki-tomcat.service
   journalctl -u pki-tomcatd@pki-tomcat.service

And the links below are about checking if CA users have correctly mapped
certificates in LDAP database in ou=people,o=ipaca for that you need
only ldapsearch command and start directory server:
   systemctl start dirsrv@YOUR-REALM-TEST.service

Proper name for dirsrv@YOUR-REALM-TEST.service can be found using:
   systemctl | grep dirsrv@



On 04/28/2016 11:07 AM, Petr Vobornik wrote:

On 04/28/2016 04:07 PM, Bret Wortman wrote:

Okay. This morning, I turned back time to 4/1 and started up IPA. It
didn't
work, but I got something new and interesting in the debug log, which
I've
posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came
pouring out
which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
   *
https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html


On 04/27/2016 02:24 PM, Bret Wortman wrote:

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
looks
logical to me, but I can't spot anything that looks like a root
cause error.
The selftests are all okay, I think. The debug log might have
something, but
it might also just be complaining about ldap not being up because
it's not.


On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?

I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.

I'd ignore the two unknown certs for now. They look like someone was
experimenting with issuing a cert and didn't quite get things working.

The CA seems to be throwing an error. I'd check the syslog for
messages from
certmonger and look at the CA debug log and selftest log.

rob


[snip]







--
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 server having cert issues

[Petr Vobornik]

On 04/28/2016 05:49 PM, Bret Wortman wrote:
> My system shows pki-server is installed and V10.2.1-3.fc21, but I don't
> have the pki-server binary itself. Will reinstalling this rpm hurt me in
> any way? Without it, I'm not sure how to check my system against the
> messages you provided below.

Not sure what you mean. Running doesn't require any additional packages.
It is just to get additional logs.
  systemctl status  pki-tomcatd@pki-tomcat.service
  journalctl -u pki-tomcatd@pki-tomcat.service

And the links below are about checking if CA users have correctly mapped
certificates in LDAP database in ou=people,o=ipaca for that you need
only ldapsearch command and start directory server:
  systemctl start dirsrv@YOUR-REALM-TEST.service

Proper name for dirsrv@YOUR-REALM-TEST.service can be found using:
  systemctl | grep dirsrv@


> 
> On 04/28/2016 11:07 AM, Petr Vobornik wrote:
>> On 04/28/2016 04:07 PM, Bret Wortman wrote:
>>> Okay. This morning, I turned back time to 4/1 and started up IPA. It
>>> didn't
>>> work, but I got something new and interesting in the debug log, which
>>> I've
>>> posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came
>>> pouring out
>>> which doesn't happen when I'm set to real time. Is /this/ significant?
>> Anything in
>>systemctl status  pki-tomcatd@pki-tomcat.service
>> or rather:
>>journalctl -u pki-tomcatd@pki-tomcat.service
>> ?
>>
>> Just to be sure, it might be also worth to check if CA subsystem users
>> have correct certs assigned:
>>   *
>> https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
>>   *
>> https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html
>>
>>>
>>> On 04/27/2016 02:24 PM, Bret Wortman wrote:
 I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It
 looks
 logical to me, but I can't spot anything that looks like a root
 cause error.
 The selftests are all okay, I think. The debug log might have
 something, but
 it might also just be complaining about ldap not being up because
 it's not.


 On 04/27/2016 01:11 PM, Rob Crittenden wrote:
> Bret Wortman wrote:
>> So in lieu of fixing these certs, is there an acceptable way to dump
>> them all and start over /without losing the contents of the IPA
>> database/? Or otherwise really screwing ourselves?
> I don't believe there is a way.
>
>> We have a replica that's still up and running and we've switched
>> everyone over to talking to it, but we're at risk with just the one.
> I'd ignore the two unknown certs for now. They look like someone was
> experimenting with issuing a cert and didn't quite get things working.
>
> The CA seems to be throwing an error. I'd check the syslog for
> messages from
> certmonger and look at the CA debug log and selftest log.
>
> rob
>
 [snip]

>>>
>>>
>>
> 


-- 
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] AD Integration - /etc/krb5.conf requirements

[Alexander Bokovoy]

On Thu, 28 Apr 2016, Alexander Bokovoy wrote:

On Thu, 28 Apr 2016, Michael ORourke wrote:

I'm just looking for some clarification from the documentation:
http://www.freeipa.org/page/Active_Directory_trust_setup

In the section that starts with "Edit /etc/krb5.conf", they mention a manual 
configuration to the krb5.conf file for machines that will be leveraging AD users:
[realms]
IPA_DOMAIN = {

auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/
auth_to_local = DEFAULT
}

Is this still required for sssd 1.13.0 and above?

The actual requirement is MIT Kerberos 1.12+ where localauth plugin
support was added. Then, of course, SSSD with localauth plugin
implementation, which is SSSD 1.12.1+.

I've updated the section 
http://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf
with the information about SSSD support for localauth plugin.

Thanks for reporting it, Michael!
--
/ Alexander Bokovoy

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

Re: [Freeipa-users] AD Integration - /etc/krb5.conf requirements

[Alexander Bokovoy]

On Thu, 28 Apr 2016, Michael ORourke wrote:

I'm just looking for some clarification from the documentation:
http://www.freeipa.org/page/Active_Directory_trust_setup

In the section that starts with "Edit /etc/krb5.conf", they mention a manual 
configuration to the krb5.conf file for machines that will be leveraging AD users:
[realms]
IPA_DOMAIN = {

 auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/
 auth_to_local = DEFAULT
}

Is this still required for sssd 1.13.0 and above?

The actual requirement is MIT Kerberos 1.12+ where localauth plugin
support was added. Then, of course, SSSD with localauth plugin
implementation, which is SSSD 1.12.1+.

--
/ Alexander Bokovoy

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

Re: [Freeipa-users] IPA server having cert issues

[Bret Wortman]

My system shows pki-server is installed and V10.2.1-3.fc21, but I don't 
have the pki-server binary itself. Will reinstalling this rpm hurt me in 
any way? Without it, I'm not sure how to check my system against the 
messages you provided below.


On 04/28/2016 11:07 AM, Petr Vobornik wrote:

On 04/28/2016 04:07 PM, Bret Wortman wrote:

Okay. This morning, I turned back time to 4/1 and started up IPA. It didn't
work, but I got something new and interesting in the debug log, which I've
posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came pouring out
which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
   systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
   journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
  * https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
  * https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html



On 04/27/2016 02:24 PM, Bret Wortman wrote:

I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It looks
logical to me, but I can't spot anything that looks like a root cause error.
The selftests are all okay, I think. The debug log might have something, but
it might also just be complaining about ldap not being up because it's not.


On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?

I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.

I'd ignore the two unknown certs for now. They look like someone was
experimenting with issuing a cert and didn't quite get things working.

The CA seems to be throwing an error. I'd check the syslog for messages from
certmonger and look at the CA debug log and selftest log.

rob


[snip]








--
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 vulnerability management SSL

[Sean Hogan]

Tenable is barking about the following.. only listing 636 but the same
applies for 389

Plugin ID: 65821  Port 636

Synopsis: The remote service supports the use of the RC4 cipher.
Description
The remote host supports the use of RC4 in one or more cipher
suites.
The RC4 cipher is flawed in its generation of a pseudo-random stream of
bytes so that a wide variety of small biases are introduced into
the stream, decreasing its randomness.


And 636 and 389 for

Plugin ID: 81606  port 389
Synopsis: The remote host supports a set of weak ciphers.
Description The remote host supports EXPORT_RSA cipher suites with keys
less than or equal to 512 bits. An attacker can factor a 512-bit RSA
modulus in a short amount of time.
A man-in-the middle attacker may be able to downgrade the session to use
EXPORT_RSA cipher suites (e.g. CVE-2015-0204). Thus, it is recommended to
remove support for weak cipher suites.

This is whay I was trying to remove  -tls_rsa_export1024_with_rc4_56_sha


Sean Hogan






From:   Sean Hogan/Durham/IBM
To: Ludwig Krispenz 
Cc: freeipa-users@redhat.com, Noriko Hosoi 
Date:   04/28/2016 08:20 AM
Subject:Re: [Freeipa-users] IPA vulnerability management SSL


Yes sir.. I am stopping DS with ipactl stop before making changes.. .I
often times have to really play with the ciphers cause many times when I
restart DS I get unknown cipher and IPA fails to start.  Go back into
dse.ldif and modify til it comes back up.




Sean Hogan
Security Engineer
Watson Security & Risk Assurance
Watson Cloud Technology and Support
email: scho...@us.ibm.com | Tel 919 486 1397









From:   Ludwig Krispenz 
To: freeipa-users@redhat.com, Noriko Hosoi 
Date:   04/28/2016 04:46 AM
Subject:Re: [Freeipa-users] IPA vulnerability management SSL
Sent by:freeipa-users-boun...@redhat.com



wanted to add Noriko, but hit send to quickly

On 04/28/2016 01:26 PM, Ludwig Krispenz wrote:
>
> On 04/28/2016 12:06 PM, Martin Kosek wrote:
>> On 04/28/2016 01:23 AM, Sean Hogan wrote:
>>> Hi Martin,
>>>
>>> No joy on placing - in front of the RC4s
>>>
>>>
>>> I modified my nss.conf to now read
>>> # SSL 3 ciphers. SSL 2 is disabled by default.
>>> NSSCipherSuite
>>>
+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha

>>>
>>>
>>> # SSL Protocol:
>>> # Cryptographic protocols that provide communication security.
>>> # NSS handles the specified protocols as "ranges", and automatically
>>> # negotiates the use of the strongest protocol for a connection
>>> starting
>>> # with the maximum specified protocol and downgrading as necessary
>>> to the
>>> # minimum specified protocol that can be used between two processes.
>>> # Since all protocol ranges are completely inclusive, and no
>>> protocol in the
>>> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
>>>
>>> dse.ldif
>>>
>>> dn: cn=encryption,cn=config
>>> objectClass: top
>>> objectClass: nsEncryptionConfig
>>> cn: encryption
>>> nsSSLSessionTimeout: 0
>>> nsSSLClientAuth: allowed
>>> nsSSL2: off
>>> nsSSL3: off
>>> creatorsName: cn=server,cn=plugins,cn=config
>>> modifiersName: cn=directory manager
>>> createTimestamp: 20150420131850Z
>>> modifyTimestamp: 20150420131906Z
>>> nsSSL3Ciphers:
>>> +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4
>>> _56_sha,-tls_dhe_dss_1024_rc4_sha
>>> numSubordinates: 1
>>>
>>>
>>>
>>> But I still get this with nmap.. I thought the above would remove
>>> -tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the
>>> fact that I am not
>>> offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really
>>> understanding
>>> where it is coming from cept the +all from DS but the - should be
>>> negating that?
>>>
>>> Starting Nmap 5.51 ( http://nmap.org  ) at
>>> 2016-04-27 17:37 EDT
>>> Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
>>> Host is up (0.86s latency).
>>> PORT STATE SERVICE
>>> 636/tcp open ldapssl
>>> | ssl-enum-ciphers:
>>> | TLSv1.2
>>> | Ciphers (13)
>>> | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
>>> | SSL_RSA_FIPS_WITH_DES_CBC_SHA
>>> | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
>>> | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
>>> | TLS_RSA_WITH_3DES_EDE_CBC_SHA
>>> | TLS_RSA_WITH_AES_128_CBC_SHA
>>> | TLS_RSA_WITH_AES_128_CBC_SHA256
>>> | TLS_RSA_WITH_AES_128_GCM_SHA256
>>> | TLS_RSA_WITH_AES_256_CBC_SHA
>>> | TLS_RSA_WITH_AES_256_CBC_SHA256
>>> | TLS_RSA_WITH_DES_CBC_SHA
>>> | TLS_RSA_WITH_RC4_128_MD5
>>> | TLS_RSA_WITH_RC4_128_SHA
>>> | Compressors (1)
>>> |_ uncompressed
>>>
>>> Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
>>>
>>>
>>>
>>> It seems no matter what config I put into nss.conf or dse.ldif
>>> nothing changes
>>> with my nmap results. Is there supposed to be a be a section to add
>>> TLS ciphers
>>> instead of SSL
>> Not sure now, CCing Ludwig who wa

[Freeipa-users] AD Integration - /etc/krb5.conf requirements

[Michael ORourke]

I'm just looking for some clarification from the documentation:
http://www.freeipa.org/page/Active_Directory_trust_setup

In the section that starts with "Edit /etc/krb5.conf", they mention a manual 
configuration to the krb5.conf file for machines that will be leveraging AD 
users:
[realms]
IPA_DOMAIN = {

  auth_to_local = RULE:[1:$1@$0](^.*@AD_DOMAIN$)s/@AD_DOMAIN/@ad_domain/
  auth_to_local = DEFAULT
}

Is this still required for sssd 1.13.0 and above?

Thanks,
Mike

-- 
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] is it possible to use 'ipa-replica' to sync userbetween different suffix AD and IPA domain?

[Matrix]

Hi, Petr


Thanks for your quickly reply.


I want to integrated linux servers with existed AD, centralized manage 
HBAC/Sudo rules. 


So i have setup a standalone IPA server with domain 'example.net', trying to 
sync users from existed AD to it with following cmd:



ipa-replica-manage connect --winsync 
--binddn="cn=ipa,cn=users,dc=examplemedia,dc=net" --bindpw='' 
--passsync='' --cacert='/etc/openldap/cacerts/ipaad.cer' 
--win-subtree='ou=users,dc=examplemedia,dc=net' -v ipaad.examplemedia.net




After it has been successfully established, users in AD did not sync to IPA. 




For 'trusts' integration method, since user did not sync to IPA at all, how to 
set sudo/HBAC rules for users? I have not tried it. 




Matrix







-- Original --
From:  "Petr Vobornik";;
Date:  Thu, Apr 28, 2016 11:21 PM
To:  "Matrix"; "freeipa-users"; 

Subject:  Re: [Freeipa-users] is it possible to use 'ipa-replica' to sync 
userbetween different suffix AD and IPA domain?



On 04/28/2016 04:44 PM, Matrix wrote:
> Hi, all
> 
> I am trying to do a centrelized solution
> 
> AD domain is 'examplemedia.net'
> 
> IPA domain is 'example.net'
> 
> After ipa-replica has been established, i found that nothing has been synced 
> from AD to IPA.
> 
> IPA version: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
> 
> I doubt that for different suffix is supported ?  If so, anyone can show some 
> hint for me to investigate more?
> 
> Thanks for your kindly help.
> 
> Matrix

Hello,

what is your goal and current setup?

By "ipa-replica has been established" do you mean that you installed a
new currently standalone IPA server? And connected it somehow with AD?

Or did you run `ipa-replica-manage connect --winsync ...`

It would be good to mention that IPA server[1] cannot be a replica of an
AD server. But it can integrate with it. Either by using
winsync(synchronization) or the recommended solution: Trusts [2].

Documentation:
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html
[2]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pt02.html

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

[Freeipa-users] Quick question regarding modifying attributes

[Sullivan, Daniel [AAA]]

Hi,

I have a trusted AD domain that I am enumerating object via IPA.  I wanted to 
know if i should be able to manipulate the uidNumber and gidNumber stored in 
the default ID view via by using the ldapmodify command, for example, for this 
DN (not local):

uid=u...@domain.edu,cn=users,cn=compat,dc=ipatst,dc=cri,dc=uchicago,dc=edu

Should it be possible to modify this via IPA’s LDAP implementation (using 
ldapmodify)?  I appreciate you taking the time to answer my question.

Thank you,

Dan Sullivan


 


This e-mail is intended only for the use of the individual or entity to which
it is addressed and may contain information that is privileged and confidential.
If the reader of this e-mail message is not the intended recipient, you are 
hereby notified that any dissemination, distribution or copying of this
communication is prohibited. If you have received this e-mail in error, please 
notify the sender and destroy all copies of the transmittal. 

Thank you
University of Chicago Medicine and Biological Sciences 


-- 
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 vulnerability management SSL

[Sean Hogan]

Yes sir.. I am stopping DS with ipactl stop before making changes.. .I
often times have to really play with the ciphers cause many times when I
restart DS I get unknown cipher and IPA fails to start.  Go back into
dse.ldif and modify til it comes back up.




Sean Hogan
Security Engineer
Watson Security & Risk Assurance
Watson Cloud Technology and Support
email: scho...@us.ibm.com | Tel 919 486 1397









From:   Ludwig Krispenz 
To: freeipa-users@redhat.com, Noriko Hosoi 
Date:   04/28/2016 04:46 AM
Subject:Re: [Freeipa-users] IPA vulnerability management SSL
Sent by:freeipa-users-boun...@redhat.com



wanted to add Noriko, but hit send to quickly

On 04/28/2016 01:26 PM, Ludwig Krispenz wrote:
>
> On 04/28/2016 12:06 PM, Martin Kosek wrote:
>> On 04/28/2016 01:23 AM, Sean Hogan wrote:
>>> Hi Martin,
>>>
>>> No joy on placing - in front of the RC4s
>>>
>>>
>>> I modified my nss.conf to now read
>>> # SSL 3 ciphers. SSL 2 is disabled by default.
>>> NSSCipherSuite
>>>
+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha

>>>
>>>
>>> # SSL Protocol:
>>> # Cryptographic protocols that provide communication security.
>>> # NSS handles the specified protocols as "ranges", and automatically
>>> # negotiates the use of the strongest protocol for a connection
>>> starting
>>> # with the maximum specified protocol and downgrading as necessary
>>> to the
>>> # minimum specified protocol that can be used between two processes.
>>> # Since all protocol ranges are completely inclusive, and no
>>> protocol in the
>>> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
>>>
>>> dse.ldif
>>>
>>> dn: cn=encryption,cn=config
>>> objectClass: top
>>> objectClass: nsEncryptionConfig
>>> cn: encryption
>>> nsSSLSessionTimeout: 0
>>> nsSSLClientAuth: allowed
>>> nsSSL2: off
>>> nsSSL3: off
>>> creatorsName: cn=server,cn=plugins,cn=config
>>> modifiersName: cn=directory manager
>>> createTimestamp: 20150420131850Z
>>> modifyTimestamp: 20150420131906Z
>>> nsSSL3Ciphers:
>>> +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4
>>> _56_sha,-tls_dhe_dss_1024_rc4_sha
>>> numSubordinates: 1
>>>
>>>
>>>
>>> But I still get this with nmap.. I thought the above would remove
>>> -tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the
>>> fact that I am not
>>> offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really
>>> understanding
>>> where it is coming from cept the +all from DS but the - should be
>>> negating that?
>>>
>>> Starting Nmap 5.51 ( http://nmap.org  ) at
>>> 2016-04-27 17:37 EDT
>>> Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
>>> Host is up (0.86s latency).
>>> PORT STATE SERVICE
>>> 636/tcp open ldapssl
>>> | ssl-enum-ciphers:
>>> | TLSv1.2
>>> | Ciphers (13)
>>> | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
>>> | SSL_RSA_FIPS_WITH_DES_CBC_SHA
>>> | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
>>> | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
>>> | TLS_RSA_WITH_3DES_EDE_CBC_SHA
>>> | TLS_RSA_WITH_AES_128_CBC_SHA
>>> | TLS_RSA_WITH_AES_128_CBC_SHA256
>>> | TLS_RSA_WITH_AES_128_GCM_SHA256
>>> | TLS_RSA_WITH_AES_256_CBC_SHA
>>> | TLS_RSA_WITH_AES_256_CBC_SHA256
>>> | TLS_RSA_WITH_DES_CBC_SHA
>>> | TLS_RSA_WITH_RC4_128_MD5
>>> | TLS_RSA_WITH_RC4_128_SHA
>>> | Compressors (1)
>>> |_ uncompressed
>>>
>>> Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
>>>
>>>
>>>
>>> It seems no matter what config I put into nss.conf or dse.ldif
>>> nothing changes
>>> with my nmap results. Is there supposed to be a be a section to add
>>> TLS ciphers
>>> instead of SSL
>> Not sure now, CCing Ludwig who was involved in the original RHEL-6
>> implementation.
> If I remember correctly we did the change in default ciphers and the
> option for handling in 389-ds > 1.3.3, so it would not be in RHEL6,
> adding Noriko to get confirmation.
>
> but the below comments about changing ciphers in dse.ldif could help
> in using the "old" way to set ciphers
>> Just to be sure, when you are modifying dse.ldif, the procedure
>> should be always following:
>>
>> 1) Stop Directory Server service
>> 2) Modify dse.ldif
>> 3) Start Directory Server service
>>
>> Otherwise it won't get applied and will get overwritten later.
>>
>> In any case, the ciphers with RHEL-6 should be secure enough, the
>> ones in
>> FreeIPA 4.3.1 should be even better. This is for example an nmap
>> taken on
>> FreeIPA Demo instance that runs on FreeIPA 4.3.1:
>>
>> $ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org
>>
>> Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-28 12:02 CEST
>> Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
>> Host is up (0.18s latency).
>> PORTSTATE SERVICE
>> 636/tcp open  ldapssl
>> | ssl-enum-ciphers:
>> |   TLSv1.2:
>> | ciphers:
>> |   TLS_ECDHE_RSA_WITH_AES_128_GCM

Re: [Freeipa-users] is it possible to use 'ipa-replica' to sync user between different suffix AD and IPA domain?

[Petr Vobornik]

On 04/28/2016 04:44 PM, Matrix wrote:
> Hi, all
> 
> I am trying to do a centrelized solution
> 
> AD domain is 'examplemedia.net'
> 
> IPA domain is 'example.net'
> 
> After ipa-replica has been established, i found that nothing has been synced 
> from AD to IPA.
> 
> IPA version: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
> 
> I doubt that for different suffix is supported ?  If so, anyone can show some 
> hint for me to investigate more?
> 
> Thanks for your kindly help.
> 
> Matrix

Hello,

what is your goal and current setup?

By "ipa-replica has been established" do you mean that you installed a
new currently standalone IPA server? And connected it somehow with AD?

Or did you run `ipa-replica-manage connect --winsync ...`

It would be good to mention that IPA server[1] cannot be a replica of an
AD server. But it can integrate with it. Either by using
winsync(synchronization) or the recommended solution: Trusts [2].

Documentation:
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html
[2]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pt02.html

HTH
-- 
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] Announcing SSSD 1.13.4

[Terry John]

>>I am plagued by the "sssd dereference processing failed : Input/output error"
>>problem. Is there any news when this version of sssd will be released for 
>>RedHat/Centos?

>If you are interested in testing of sssd-1.13.4 then you can test 
>upstream(backported from fedora) version in copr.
>https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

Ok thanks
I'll see if I can give it a try
Terry


The Manheim group of companies within the UK comprises: Manheim Europe Limited 
(registered number: 03183918), Manheim Auctions Limited (registered number: 
00448761), Manheim Retail Services Limited (registered number: 02838588), 
Motors.co.uk Limited (registered number: 05975777), Real Time Communications 
Limited (registered number: 04277845) and Complete Automotive Solutions Limited 
(registered number: 05302535). Each of these companies is registered in England 
and Wales with the registered office address of Central House, Leeds Road, 
Rothwell, Leeds LS26 0JE. The Manheim group of companies operates under various 
brand/trading names including Manheim Inspection Services, Manheim Auctions, 
Manheim Direct, Manheim De-fleet and Manheim Aftersales Solutions.

V:0CF72C13B2AC



-- 
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 server having cert issues

[Petr Vobornik]

On 04/28/2016 04:07 PM, Bret Wortman wrote:
> Okay. This morning, I turned back time to 4/1 and started up IPA. It didn't 
> work, but I got something new and interesting in the debug log, which I've 
> posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk came pouring out 
> which doesn't happen when I'm set to real time. Is /this/ significant?

Anything in
  systemctl status  pki-tomcatd@pki-tomcat.service
or rather:
  journalctl -u pki-tomcatd@pki-tomcat.service
?

Just to be sure, it might be also worth to check if CA subsystem users
have correct certs assigned:
 * https://www.redhat.com/archives/freeipa-users/2016-April/msg00138.html
 * https://www.redhat.com/archives/freeipa-users/2016-April/msg00143.html

> 
> 
> On 04/27/2016 02:24 PM, Bret Wortman wrote:
>> I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It looks 
>> logical to me, but I can't spot anything that looks like a root cause error. 
>> The selftests are all okay, I think. The debug log might have something, but 
>> it might also just be complaining about ldap not being up because it's not.
>>
>>
>> On 04/27/2016 01:11 PM, Rob Crittenden wrote:
>>> Bret Wortman wrote:
 So in lieu of fixing these certs, is there an acceptable way to dump
 them all and start over /without losing the contents of the IPA
 database/? Or otherwise really screwing ourselves?
>>>
>>> I don't believe there is a way.
>>>
 We have a replica that's still up and running and we've switched
 everyone over to talking to it, but we're at risk with just the one.
>>>
>>> I'd ignore the two unknown certs for now. They look like someone was 
>>> experimenting with issuing a cert and didn't quite get things working.
>>>
>>> The CA seems to be throwing an error. I'd check the syslog for messages 
>>> from 
>>> certmonger and look at the CA debug log and selftest log.
>>>
>>> rob
>>>
>> [snip]
>>
> 
> 
> 


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

[Freeipa-users] is it possible to use 'ipa-replica' to sync user between different suffix AD and IPA domain?

[Matrix]

Hi, all


I am trying to do a centrelized solution 


AD domain is 'examplemedia.net'


IPA domain is 'example.net'


After ipa-replica has been established, i found that nothing has been synced 
from AD to IPA. 


IPA version: ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64


I doubt that for different suffix is supported ?  If so, anyone can show some 
hint for me to investigate more? 


Thanks for your kindly help.


Matrix-- 
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 server having cert issues

[Bret Wortman]

Okay. This morning, I turned back time to 4/1 and started up IPA. It 
didn't work, but I got something new and interesting in the debug log, 
which I've posted to http://pastebin.com/M9VGCS8A. Lots of garbled junk 
came pouring out which doesn't happen when I'm set to real time. Is 
/this/ significant?



On 04/27/2016 02:24 PM, Bret Wortman wrote:
I put excerpts from the ca logs in http://pastebin.com/gYgskU79. It 
looks logical to me, but I can't spot anything that looks like a root 
cause error. The selftests are all okay, I think. The debug log might 
have something, but it might also just be complaining about ldap not 
being up because it's not.



On 04/27/2016 01:11 PM, Rob Crittenden wrote:

Bret Wortman wrote:

So in lieu of fixing these certs, is there an acceptable way to dump
them all and start over /without losing the contents of the IPA
database/? Or otherwise really screwing ourselves?


I don't believe there is a way.


We have a replica that's still up and running and we've switched
everyone over to talking to it, but we're at risk with just the one.


I'd ignore the two unknown certs for now. They look like someone was 
experimenting with issuing a cert and didn't quite get things working.


The CA seems to be throwing an error. I'd check the syslog for 
messages from certmonger and look at the CA debug log and selftest log.


rob


[snip]



-- 
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] ca-error: Error setting up ccache for local "host" service using default keytab: Clock skew too great.

[Anthony Cheng]

klist is actually empty; kinit admin fails.  Sounds like then getcert
resubmit has a dependency on kerberoes.  I can get a backup image that has
a valid ticket but it is only good for 1 day (and dated pasted the cert
expire).

Also I had asked awhile back about whether there is dependency on DIRSRV to
renew the cert; didn't get any response but I suspect there is a dependency.

Regarding the clock skew, I found out from /var/log/message that shows me
this so it may be from named:

Jan 28 14:10:42 test named[2911]: Failed to init credentials (Clock skew
too great)
Jan 28 14:10:42 test named[2911]: loading configuration: failure
Jan 28 14:10:42 test named[2911]: exiting (due to fatal error)
Jan 28 14:10:44 test ns-slapd: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Creden
tials cache file '/tmp/krb5cc_496' not found)

I don't have a krb5cc_496 file (since klist is empty), so sounds to me I
need to get a kerberoes ticket before going any further.  Also is the file
/etc/krb5.keytab access/modification time important?  I had changed time
back to before the cert expiration date and reboot and try renew but the
error message about clock skew is still there.  That seems strange.

Lastly, as a absolute last resort, can I regenerate a new cert myself?
https://www.centos.org/docs/5/html/CDS/ag/8.0/Managing_SSL-Using_certutil.html

[root@test /]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@test /]# service ipa start
Starting Directory Service
Starting dirsrv:
PKI-IPA... [  OK  ]
sample-NET...  [  OK  ]
Starting KDC Service
Starting Kerberos 5 KDC:   [  OK  ]
Starting KPASSWD Service
Starting Kerberos 5 Admin Server:  [  OK  ]
Starting DNS Service
Starting named:[FAILED]
Failed to start DNS Service
Shutting down
Stopping Kerberos 5 KDC:   [  OK  ]
Stopping Kerberos 5 Admin Server:  [  OK  ]
Stopping named:[  OK  ]
Stopping httpd:[  OK  ]
Stopping pki-ca:   [  OK  ]
Shutting down dirsrv:
PKI-IPA... [  OK  ]
sample-NET...  [  OK  ]
Aborting ipactl
[root@test /]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
[root@test /]# service ipa status
Directory Service: STOPPED
Failed to get list of services to probe status:
Directory Server is stopped

On Thu, Apr 28, 2016 at 3:21 AM David Kupka  wrote:

> On 27/04/16 21:54, Anthony Cheng wrote:
> > Hi list,
> >
> > I am trying to renew expired certificates following the manual renewal
> procedure
> > here (http://www.freeipa.org/page/IPA_2x_Certificate_Renewal) but even
> with
> > resetting the system/hardware clock to a time before expires, I am
> getting the
> > error "ca-error: Error setting up ccache for local "host" service using
> default
> > keytab: Clock skew too great."
> >
> > With NTP disable and clock reset why would it complain about clock skew
> and how
> > does it even know about the current time?
> >
> > [root@test certs]# getcert list
> > Number of certificates and requests being tracked: 8.
> > Request ID '20111214223243':
> >  status: MONITORING
> >  ca-error: Error setting up ccache for local "host" service using
> > default keytab: Clock skew too great.
> >  stuck: no
> >  key pair storage:
> >
> type=NSSDB,location='/etc/dirsrv/slapd-sample-NET',nickname='Server-Cert',token='NSS
> > Certificate DB',pinfile='/etc/dirsrv/slapd-sample-NET//pwdfile.txt'
> >  certificate:
> >
> type=NSSDB,location='/etc/dirsrv/slapd-sample-NET',nickname='Server-Cert',token='NSS
> > Certificate DB'
> >  CA: IPA
> >  issuer: CN=Certificate Authority,O=sample.NET
> >  subject: CN=test.sample.net  >,O=sample.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: MONITORING
> >  ca-error: Error setting up ccache for local "host" service using
> > default keytab: Clock skew too great.
> >  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=sample.NET
> >  subject: CN=test.sam

Re: [Freeipa-users] Announcing SSSD 1.13.4

[Lukas Slebodnik]

On (28/04/16 09:08), Terry John wrote:
>I am plagued by the "sssd dereference processing failed : Input/output error"
>problem. Is there any news when this version of sssd will be released
>for RedHat/Centos?
>
If you are interested in testing of sssd-1.13.4
then you can test upstream(backported from fedora) version
in copr.

https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-13/

LS

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

Re: [Freeipa-users] IPA vulnerability management SSL

[Ludwig Krispenz]

wanted to add Noriko, but hit send to quickly

On 04/28/2016 01:26 PM, Ludwig Krispenz wrote:


On 04/28/2016 12:06 PM, Martin Kosek wrote:

On 04/28/2016 01:23 AM, Sean Hogan wrote:

Hi Martin,

No joy on placing - in front of the RC4s


I modified my nss.conf to now read
# SSL 3 ciphers. SSL 2 is disabled by default.
NSSCipherSuite
+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha 



# SSL Protocol:
# Cryptographic protocols that provide communication security.
# NSS handles the specified protocols as "ranges", and automatically
# negotiates the use of the strongest protocol for a connection 
starting
# with the maximum specified protocol and downgrading as necessary 
to the

# minimum specified protocol that can be used between two processes.
# Since all protocol ranges are completely inclusive, and no 
protocol in the

NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

dse.ldif

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off
nsSSL3: off
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20150420131850Z
modifyTimestamp: 20150420131906Z
nsSSL3Ciphers: 
+all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4

_56_sha,-tls_dhe_dss_1024_rc4_sha
numSubordinates: 1



But I still get this with nmap.. I thought the above would remove
-tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the 
fact that I am not
offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really 
understanding
where it is coming from cept the +all from DS but the - should be 
negating that?


Starting Nmap 5.51 ( http://nmap.org  ) at 
2016-04-27 17:37 EDT

Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
Host is up (0.86s latency).
PORT STATE SERVICE
636/tcp open ldapssl
| ssl-enum-ciphers:
| TLSv1.2
| Ciphers (13)
| SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
| SSL_RSA_FIPS_WITH_DES_CBC_SHA
| TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
| TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA256
| TLS_RSA_WITH_AES_128_GCM_SHA256
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA256
| TLS_RSA_WITH_DES_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
|_ uncompressed

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds



It seems no matter what config I put into nss.conf or dse.ldif 
nothing changes
with my nmap results. Is there supposed to be a be a section to add 
TLS ciphers

instead of SSL

Not sure now, CCing Ludwig who was involved in the original RHEL-6
implementation.
If I remember correctly we did the change in default ciphers and the 
option for handling in 389-ds > 1.3.3, so it would not be in RHEL6, 
adding Noriko to get confirmation.


but the below comments about changing ciphers in dse.ldif could help 
in using the "old" way to set ciphers

Just to be sure, when you are modifying dse.ldif, the procedure
should be always following:

1) Stop Directory Server service
2) Modify dse.ldif
3) Start Directory Server service

Otherwise it won't get applied and will get overwritten later.

In any case, the ciphers with RHEL-6 should be secure enough, the 
ones in
FreeIPA 4.3.1 should be even better. This is for example an nmap 
taken on

FreeIPA Demo instance that runs on FreeIPA 4.3.1:

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-28 12:02 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.18s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 21.12 seconds

Martin




--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen

Re: [Freeipa-users] IPA vulnerability management SSL

[Ludwig Krispenz]

On 04/28/2016 12:06 PM, Martin Kosek wrote:

On 04/28/2016 01:23 AM, Sean Hogan wrote:

Hi Martin,

No joy on placing - in front of the RC4s


I modified my nss.conf to now read
# SSL 3 ciphers. SSL 2 is disabled by default.
NSSCipherSuite
+aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha

# SSL Protocol:
# Cryptographic protocols that provide communication security.
# NSS handles the specified protocols as "ranges", and automatically
# negotiates the use of the strongest protocol for a connection starting
# with the maximum specified protocol and downgrading as necessary to the
# minimum specified protocol that can be used between two processes.
# Since all protocol ranges are completely inclusive, and no protocol in the
NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2

dse.ldif

dn: cn=encryption,cn=config
objectClass: top
objectClass: nsEncryptionConfig
cn: encryption
nsSSLSessionTimeout: 0
nsSSLClientAuth: allowed
nsSSL2: off
nsSSL3: off
creatorsName: cn=server,cn=plugins,cn=config
modifiersName: cn=directory manager
createTimestamp: 20150420131850Z
modifyTimestamp: 20150420131906Z
nsSSL3Ciphers: +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4
_56_sha,-tls_dhe_dss_1024_rc4_sha
numSubordinates: 1



But I still get this with nmap.. I thought the above would remove
-tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the fact that I am 
not
offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really understanding
where it is coming from cept the +all from DS but the - should be negating that?

Starting Nmap 5.51 ( http://nmap.org  ) at 2016-04-27 17:37 
EDT
Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
Host is up (0.86s latency).
PORT STATE SERVICE
636/tcp open ldapssl
| ssl-enum-ciphers:
| TLSv1.2
| Ciphers (13)
| SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
| SSL_RSA_FIPS_WITH_DES_CBC_SHA
| TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
| TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
| TLS_RSA_WITH_3DES_EDE_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA
| TLS_RSA_WITH_AES_128_CBC_SHA256
| TLS_RSA_WITH_AES_128_GCM_SHA256
| TLS_RSA_WITH_AES_256_CBC_SHA
| TLS_RSA_WITH_AES_256_CBC_SHA256
| TLS_RSA_WITH_DES_CBC_SHA
| TLS_RSA_WITH_RC4_128_MD5
| TLS_RSA_WITH_RC4_128_SHA
| Compressors (1)
|_ uncompressed

Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds



It seems no matter what config I put into nss.conf or dse.ldif nothing changes
with my nmap results. Is there supposed to be a be a section to add TLS ciphers
instead of SSL

Not sure now, CCing Ludwig who was involved in the original RHEL-6
implementation.
If I remember correctly we did the change in default ciphers and the 
option for handling in 389-ds > 1.3.3, so it would not be in RHEL6, 
adding Noriko to get confirmation.


but the below comments about changing ciphers in dse.ldif could help in 
using the "old" way to set ciphers

Just to be sure, when you are modifying dse.ldif, the procedure
should be always following:

1) Stop Directory Server service
2) Modify dse.ldif
3) Start Directory Server service

Otherwise it won't get applied and will get overwritten later.

In any case, the ciphers with RHEL-6 should be secure enough, the ones in
FreeIPA 4.3.1 should be even better. This is for example an nmap taken on
FreeIPA Demo instance that runs on FreeIPA 4.3.1:

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-28 12:02 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.18s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 21.12 seconds

Martin


--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham, Michael 
O'Neill

--
Manage your 

Re: [Freeipa-users] Replication error

[Petr Vobornik]

On 04/26/2016 02:02 PM, Anton Rubets wrote:
> Hhi all
> 
> I have issues with replication between to FreeIPA server
> 
> In maters log
> 
> [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap2.domain:389/o%3Dipaca) failed.
> [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap2.domain:389/o%3Dipaca) failed.
> [26/Apr/2016:10:38:12 +0200] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap2.domain389/o%3Dipaca) failed.
> [26/Apr/2016:10:39:35 +0200] slapi_ldap_bind - Error: could not send startTLS 
> request: error -1 (Can't contact LDAP server) errno 2 (No such file or 
> directory)
> 
> 
> On replica server
> 
> 
> [26/Apr/2016:08:38:12 +] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap1.domain:389/o%3Dipaca) failed.
> [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap1domain:389/o%3Dipaca) failed.
> [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap1.domain:389/o%3Dipaca) failed.
> [26/Apr/2016:08:43:13 +] attrlist_replace - attr_replace 
> (nsslapd-referral, 
> ldap://ldap1.domain:389/o%3Dipaca) failed.

This is a symptom of dangling RUVs (replica update vector) of previously
removed replicas.

It happens when replica is removed using:
  # ipa-replica-manage del $replica
  # ipa-server-install --uninstall (on replica)

without running:
  # ipa-csreplica-manage del $replica
first

resolution is to clear the RUVs manually using clean ruv DS task becase
ipa-csreplica-manage doesn't have support for it. FreeIPA 4.4 will
receive a new command which will handle bot suffixes automatically - #5411.

The instructions can found on the list:
* https://www.redhat.com/archives/freeipa-users/2015-June/msg00386.html
* https://www.redhat.com/archives/freeipa-users/2015-June/msg00416.html

and
* http://www.port389.org/docs/389ds/FAQ/troubleshoot-cleanallruv.html
* or general procedure for future feature:
https://fedorahosted.org/freeipa/ticket/5411#comment:7


Important: Be very careful not to remove RUVs of existing replicas.


> 
> 
> And  i can't find source of this problem. I have checked permission and etc. 
> As 
> i see replica is working but this message disturb my email every few minutes 
> and 
> i wanna somehow fix this. Also I  just migrate from 3.0 to 4.2.
> Info:
> Master :
>   rpm -qa | grep ipa
> ipa-server-dns-4.2.0-15.0.1.el7.centos.6.x86_64
> ipa-admintools-4.2.0-15.0.1.el7.centos.6.x86_64
> sssd-ipa-1.13.0-40.el7_2.2.x86_64
> ipa-client-4.2.0-15.0.1.el7.centos.6.x86_64
> libipa_hbac-1.13.0-40.el7_2.2.x86_64
> python-libipa_hbac-1.13.0-40.el7_2.2.x86_64
> python-iniparse-0.4-9.el7.noarch
> ipa-python-4.2.0-15.0.1.el7.centos.6.x86_64
> ipa-server-4.2.0-15.0.1.el7.centos.6.x86_64​
> 
> Replica:
> rpm -qa | grep ipa
> sssd-ipa-1.13.0-40.el7_2.2.x86_64
> ipa-admintools-4.2.0-15.0.1.el7.centos.6.1.x86_64
> libipa_hbac-1.13.0-40.el7_2.2.x86_64
> ipa-client-4.2.0-15.0.1.el7.centos.6.1.x86_64
> ipa-python-4.2.0-15.0.1.el7.centos.6.1.x86_64
> ipa-server-dns-4.2.0-15.0.1.el7.centos.6.1.x86_64
> python-libipa_hbac-1.13.0-40.el7_2.2.x86_64
> python-iniparse-0.4-9.el7.noarch
> ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64​
> 
> 
> Best Regards
> Anton Rubets
-- 
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] IPA vulnerability management SSL

[Martin Kosek]

On 04/28/2016 01:23 AM, Sean Hogan wrote:
> Hi Martin,
> 
> No joy on placing - in front of the RC4s
> 
> 
> I modified my nss.conf to now read
> # SSL 3 ciphers. SSL 2 is disabled by default.
> NSSCipherSuite 
> +aes_128_sha_256,+aes_256_sha_256,+ecdhe_ecdsa_aes_128_gcm_sha_256,+ecdhe_ecdsa_aes_128_sha,+ecdhe_ecdsa_aes_256_sha,+ecdhe_rsa_aes_128_gcm_sha_256,+ecdhe_rsa_aes_128_sha,+ecdhe_rsa_aes_256_sha,+rsa_aes_128_gcm_sha_256,+rsa_aes_128_sha,+rsa_aes_256_sha
> 
> # SSL Protocol:
> # Cryptographic protocols that provide communication security.
> # NSS handles the specified protocols as "ranges", and automatically
> # negotiates the use of the strongest protocol for a connection starting
> # with the maximum specified protocol and downgrading as necessary to the
> # minimum specified protocol that can be used between two processes.
> # Since all protocol ranges are completely inclusive, and no protocol in the
> NSSProtocol TLSv1.0,TLSv1.1,TLSv1.2
> 
> dse.ldif
> 
> dn: cn=encryption,cn=config
> objectClass: top
> objectClass: nsEncryptionConfig
> cn: encryption
> nsSSLSessionTimeout: 0
> nsSSLClientAuth: allowed
> nsSSL2: off
> nsSSL3: off
> creatorsName: cn=server,cn=plugins,cn=config
> modifiersName: cn=directory manager
> createTimestamp: 20150420131850Z
> modifyTimestamp: 20150420131906Z
> nsSSL3Ciphers: +all,-rsa_null_sha,-rsa_rc4_56_sha,-tls_rsa_export1024_with_rc4
> _56_sha,-tls_dhe_dss_1024_rc4_sha
> numSubordinates: 1
> 
> 
> 
> But I still get this with nmap.. I thought the above would remove 
> -tls_rsa_export1024_with_rc4_56_sha but still showing. Is it the fact that I 
> am not
> offering -tls_rsa_export1024_with_rc4_56_sha? If so.. not really 
> understanding 
> where it is coming from cept the +all from DS but the - should be negating 
> that?
> 
> Starting Nmap 5.51 ( http://nmap.org  ) at 2016-04-27 17:37 
> EDT
> Nmap scan report for rtpvxl0077.watson.local (10.110.76.242)
> Host is up (0.86s latency).
> PORT STATE SERVICE
> 636/tcp open ldapssl
> | ssl-enum-ciphers:
> | TLSv1.2
> | Ciphers (13)
> | SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
> | SSL_RSA_FIPS_WITH_DES_CBC_SHA
> | TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
> | TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
> | TLS_RSA_WITH_3DES_EDE_CBC_SHA
> | TLS_RSA_WITH_AES_128_CBC_SHA
> | TLS_RSA_WITH_AES_128_CBC_SHA256
> | TLS_RSA_WITH_AES_128_GCM_SHA256
> | TLS_RSA_WITH_AES_256_CBC_SHA
> | TLS_RSA_WITH_AES_256_CBC_SHA256
> | TLS_RSA_WITH_DES_CBC_SHA
> | TLS_RSA_WITH_RC4_128_MD5
> | TLS_RSA_WITH_RC4_128_SHA
> | Compressors (1)
> |_ uncompressed
> 
> Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds
> 
> 
> 
> It seems no matter what config I put into nss.conf or dse.ldif nothing 
> changes 
> with my nmap results. Is there supposed to be a be a section to add TLS 
> ciphers 
> instead of SSL

Not sure now, CCing Ludwig who was involved in the original RHEL-6
implementation. Just to be sure, when you are modifying dse.ldif, the procedure
should be always following:

1) Stop Directory Server service
2) Modify dse.ldif
3) Start Directory Server service

Otherwise it won't get applied and will get overwritten later.

In any case, the ciphers with RHEL-6 should be secure enough, the ones in
FreeIPA 4.3.1 should be even better. This is for example an nmap taken on
FreeIPA Demo instance that runs on FreeIPA 4.3.1:

$ nmap --script ssl-enum-ciphers -p 636 ipa.demo1.freeipa.org

Starting Nmap 7.12 ( https://nmap.org ) at 2016-04-28 12:02 CEST
Nmap scan report for ipa.demo1.freeipa.org (209.132.178.99)
Host is up (0.18s latency).
PORTSTATE SERVICE
636/tcp open  ldapssl
| ssl-enum-ciphers:
|   TLSv1.2:
| ciphers:
|   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|   TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|   TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|   TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|   TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
| compressors:
|   NULL
| cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 21.12 seconds

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] Announcing SSSD 1.13.4

[Jakub Hrozek]

On Thu, Apr 28, 2016 at 09:08:18AM +, Terry John wrote:
> I am plagued by the "sssd dereference processing failed : Input/output error" 
> problem. Is there any news when this version of sssd will be released for 
> RedHat/Centos?
> 
> My current version is: 1.12.4-47.el6

RHEL-6.8. But please note that in most cases it's just a harmless error
message. Do you actually see some issue or just an annoying message in
the logs?


> 
> Terry
> 
> -Original Message-
> From: freeipa-users-boun...@redhat.com 
> [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
> Sent: 14 April 2016 16:17
> To: sssd-de...@lists.fedorahosted.org; sssd-us...@lists.fedorahosted.org; 
> freeipa-users@redhat.com; freeipa-inter...@redhat.com
> Subject: [Freeipa-users] Announcing SSSD 1.13.4
> 
> == SSSD 1.13.4 ===
> 
> The SSSD team is proud to announce the release of version 1.13.4 of the 
> System Security Services Daemon.
> 
> As always, the source is available from https://fedorahosted.org/sssd
> 
> RPM packages will be made available for Fedora shortly.
> 
> == Feedback ==
> Please provide comments, bugs and other feedback via the sssd-devel or 
> sssd-users mailing lists:
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> 
> == Highlights ==
> * The IPA sudo provider was reimplemented. The new version reads the
>   data from IPA's LDAP tree (as opposed to the compat tree populated by
>   the slapi-nis plugin that was used previously). The benefit is that
>   deployments which don't require the compat tree for other purposes,
>   such as support for non-SSSD clients can disable those autogenerated
>   LDAP trees to conserve resources that slapi-nis otherwise requires. 
> There
>   should be no visible changes to the end user.
> * SSSD now has the ability to renew the machine credentials (keytabs)
>   when the ad provider is used. Please note that a recent version of
>   the adcli (0.8 or newer) package is required for this feature to work.
> * The automatic ID mapping feature was improved so that the administrator
>   is no longer required to manually set the range size in case a RID in
>   the AD domain is larger than the default range size
> * A potential infinite loop in the NFS ID mapping plugin that was
>   resulting in an excessive memory usage was fixed
> * Clients that are pinned to a particular AD site using the ad_site
>   option no longer communicate with DCs outside that site during service
>   discovery.
> * The IPA identity provider is now able to resolve external
>   (typically coming from a trusted AD forest) group members during
>   get-group-information requests. Please note that resolving external
>   group memberships for AD users during the initgroup requests used to
>   work even prior to this update. This feature is mostly useful for cases
>   where an IPA client is using the compat tree to resolve AD trust users.
> * The IPA ID views feature now works correctly even for deployments
>   without a trust relationship. Previously, the subdomains IPA provider
>   failed to read the views data if no master domain record was created
>   on the IPA server during trust establishment.
> * A race condition in the client libraries between the SSSD closing
>   the socket as idle and the client application using the socket was
>   fixed. This bug manifested with a Broken Pipe error message on the
>   client.
> * SSSD is now able to resolve users with the same usernames in different
>   OUs of an AD domain
> * The smartcard authentication now works properly with gnome-screensaver
> 
> == Packaging Changes ==
> * The krb5.include.d directory is now owned by the sssd user and
>   packaged in the krb5-common subpackage
> 
> == Documentation Changes ==
> * A new option ldap_idmap_helper_table_size was added. This option can
>   help tune allocation of new ID mapping slices for AD domains with a high
>   RID values. Most deployments can use the default value of this option.
> * Several PAM services were added to the lists that are used to map
>   Windows logon services to Linux PAM services. The newly added PAM
>   services include login managers (lightdm, lxdm, sddm and xdm) as well
>   as the cockpit service.
> * The AD machine credentials renewal task can be fine-tuned using
>   the ad_machine_account_password_renewal_opts to change the initial
>   delay and period of the credentials renewal task. In addition, the new
>   ad_maximum_machine_account_password_age option allows the administrator
>   to select how old the machine credential must be before trying to
>   renew it.
> * The administrator can use the new option pam_account_locked_message to
>   set a custom informational message whe

Re: [Freeipa-users] ipa-client password authentication failed

[Rakesh Rajasekharan]

somehow, i am no longer facing this issue.. the only change I did was,
corrected the /etc/openldap/ldap.conf file to point to the ipa master dns
rather than the older ldap dns.
the file had "#File modified by ipa-client-install" but it did not change
the ldap dns and still pointed to older entry. I jsut corrected it and
restarted sssd.

It though did not work initially after changing , however, I am no longer
facing that issue now.  may be it was a caching issue

Thanks,
Rakesh

On Sun, Apr 24, 2016 at 5:01 PM, Jakub Hrozek  wrote:

>
> > On 22 Apr 2016, at 19:21, Rakesh Rajasekharan <
> rakesh.rajasekha...@gmail.com> wrote:
> >
> > Hi Jakub
> >
> >
> > the child only had that much info..
> >
> > from the domain logs. it looks that it was able to resolve the master .
> However, the ldap results say found nothing.
> >
> > I was earlier running an openldap client on this host and then migrated
> to IPA.
> >
> > /etc/openldap/ldap.conf  was still pointing to the older ldap master..
> >
> > #File modified by ipa-client-install
> >
> > URI ldaps://older-ldap-master.com:636/
> > BASE dc=xyz,dc=com
> > TLS_CACERT /etc/ipa/ca.crt
> >
> > TLS_CACERTDIR /etc/openldap/cacerts]
> >
> > I corrected that to point to IPA and noticed that getent passwd now
> successfully lists all the users.
> > However, the authentication does not work yet. ( ldapsearch -x though
> shows all the users ).
> >
> > I re-tested it now...
> > below is the domain log
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): start
> ldb transaction (nesting: 3)
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Added
> timed event "ltdb_callback": 0x118fab0
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Added
> timed event "ltdb_timeout": 0x11925f0
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Running
> timer event 0x118fab0 "ltdb_callback"
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000):
> Destroying timer event 0x11925f0 "ltdb_timeout"
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Ending
> timer event 0x118fab0 "ltdb_callback"
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): cancel
> ldb transaction (nesting: 3)
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 2)
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 1)
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_save_users]
> (0x4000): User 0 processed!
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): commit
> ldb transaction (nesting: 0)
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_get_users_done]
> (0x4000): Saving 1 Users - Done
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_id_op_done]
> (0x4000): releasing operation connection
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Added
> timed event "ltdb_callback": 0x118fd20
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Added
> timed event "ltdb_timeout": 0x1182770
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Running
> timer event 0x118fd20 "ltdb_callback"
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000):
> Destroying timer event 0x1182770 "ltdb_timeout"
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [ldb] (0x4000): Ending
> timer event 0x118fd20 "ltdb_callback"
> >
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]]
> [sdap_id_op_connect_step] (0x4000): reusing cached connection
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]]
> [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in
> view [Default Trust View] with filter
> [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:xyz.com:8
> c7e86dc-0536-11e6-94f8-0e49bd988575))].
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_print_server]
> (0x2000): Searching 10.0.4.175
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
> [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:IPA:xyz.com:8c7e86dc-0536-11e6-94f8-0e49bd988575))][cn=Default
> Trust View,cn=views,cn=accounts,dc=xyz,dc=com].
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 105
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x1173050], connected[1], ops[0x115c810],
> ldap[0x1164b30]
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_process_result]
> (0x2000): Trace: ldap_result found nothing!
> > (Fri Apr 22 16:57:21 2016) [sssd[be[xyz.com]]] [sdap_process_result]
> (0x2000): Trace: sh[0x1173050], connected[1], ops[0x115c810], ldap[0x1164b30
> >
>
> This log snippet is again completely unrelated to login. It just says
> there are no overrides applicable for this user. Please run:
>
> date; ssh $user@$host; date;
>
> and attac

Re: [Freeipa-users] Announcing SSSD 1.13.4

[Terry John]

I am plagued by the "sssd dereference processing failed : Input/output error" 
problem. Is there any news when this version of sssd will be released for 
RedHat/Centos?

My current version is: 1.12.4-47.el6

Terry

-Original Message-
From: freeipa-users-boun...@redhat.com 
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Jakub Hrozek
Sent: 14 April 2016 16:17
To: sssd-de...@lists.fedorahosted.org; sssd-us...@lists.fedorahosted.org; 
freeipa-users@redhat.com; freeipa-inter...@redhat.com
Subject: [Freeipa-users] Announcing SSSD 1.13.4

== SSSD 1.13.4 ===

The SSSD team is proud to announce the release of version 1.13.4 of the System 
Security Services Daemon.

As always, the source is available from https://fedorahosted.org/sssd

RPM packages will be made available for Fedora shortly.

== Feedback ==
Please provide comments, bugs and other feedback via the sssd-devel or 
sssd-users mailing lists:
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
https://lists.fedorahosted.org/mailman/listinfo/sssd-users

== Highlights ==
* The IPA sudo provider was reimplemented. The new version reads the
  data from IPA's LDAP tree (as opposed to the compat tree populated by
  the slapi-nis plugin that was used previously). The benefit is that
  deployments which don't require the compat tree for other purposes,
  such as support for non-SSSD clients can disable those autogenerated
  LDAP trees to conserve resources that slapi-nis otherwise requires. There
  should be no visible changes to the end user.
* SSSD now has the ability to renew the machine credentials (keytabs)
  when the ad provider is used. Please note that a recent version of
  the adcli (0.8 or newer) package is required for this feature to work.
* The automatic ID mapping feature was improved so that the administrator
  is no longer required to manually set the range size in case a RID in
  the AD domain is larger than the default range size
* A potential infinite loop in the NFS ID mapping plugin that was
  resulting in an excessive memory usage was fixed
* Clients that are pinned to a particular AD site using the ad_site
  option no longer communicate with DCs outside that site during service
  discovery.
* The IPA identity provider is now able to resolve external
  (typically coming from a trusted AD forest) group members during
  get-group-information requests. Please note that resolving external
  group memberships for AD users during the initgroup requests used to
  work even prior to this update. This feature is mostly useful for cases
  where an IPA client is using the compat tree to resolve AD trust users.
* The IPA ID views feature now works correctly even for deployments
  without a trust relationship. Previously, the subdomains IPA provider
  failed to read the views data if no master domain record was created
  on the IPA server during trust establishment.
* A race condition in the client libraries between the SSSD closing
  the socket as idle and the client application using the socket was
  fixed. This bug manifested with a Broken Pipe error message on the
  client.
* SSSD is now able to resolve users with the same usernames in different
  OUs of an AD domain
* The smartcard authentication now works properly with gnome-screensaver

== Packaging Changes ==
* The krb5.include.d directory is now owned by the sssd user and
  packaged in the krb5-common subpackage

== Documentation Changes ==
* A new option ldap_idmap_helper_table_size was added. This option can
  help tune allocation of new ID mapping slices for AD domains with a high
  RID values. Most deployments can use the default value of this option.
* Several PAM services were added to the lists that are used to map
  Windows logon services to Linux PAM services. The newly added PAM
  services include login managers (lightdm, lxdm, sddm and xdm) as well
  as the cockpit service.
* The AD machine credentials renewal task can be fine-tuned using
  the ad_machine_account_password_renewal_opts to change the initial
  delay and period of the credentials renewal task. In addition, the new
  ad_maximum_machine_account_password_age option allows the administrator
  to select how old the machine credential must be before trying to
  renew it.
* The administrator can use the new option pam_account_locked_message to
  set a custom informational message when the account logging in is locked.

== Tickets Fixed ==
https://fedorahosted.org/sssd/ticket/1041
[RFE] Support Automatic Renewing of Kerberos Host Keytabs
https://fedorahosted.org/sssd/ticket/1108
[RFE] SUDO: Support the IPA schema
https://fedorahosted.org/sssd/ticket/2188
automatically assign new slices for any AD domain
https://fedorahosted.org/sssd/ticket/2522
[RFE] IPA: 

Re: [Freeipa-users] can live turn off nsslapd-security: to off ?

[Barry]

Already set nsslapd:sceruity off on server 1 <> server 2

BUt still produce error on replication. Is it possible to ignore any cert /
start tLS ?

/var/log/dirsrv/slapd-PKI-IPA
[28/Apr/2016:16:51:15 +0800] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport
endpoint is not connected)

[26/Apr/2016:18:35:31 +0800] slapd_ldap_sasl_interactive_bind - Error:
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error -1
(Can't contact LDAP server) ((null)) errno 107 (Transport endpoint is not
connected)

2016-04-28 16:15 GMT+08:00 Martin Basti :

>
>
> On 28.04.2016 08:00, Barry wrote:
>
> NOT work tried ..cannot bind the command 389 or 636 ,,,but telnet work
>
> EOFnsslapd-security: offreplace: nsslapd-securitychangetype: modifydn:
> cn=configldapmodify -h ms -p 636 -D cn="Directory Manager" -w  << EOF
>
> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
> can you please try to put FQDN name of LDAP server to option -h ?
> I have doubts that -h 'ms' is server name
>
> Martin
>
>
>
> 2016-04-27 19:29 GMT+08:00 :
>
>> thx let me try as i dont want stop dirsrv but live disable nsslapd
>> security.
>> 2016年4月27日 下午7:26 於 "David Kupka"  寫道：
>>
>>> On 27/04/16 13:15, barry...@gmail.com wrote:
>>>
 Do u meant use ldapmodify?
 I tried update the dse.ldif but it will fall back after a while.

 2016年4月27日 下午7:10 於 "David Kupka" >>> > 寫道：

 On 27/04/16 12:48, barry...@gmail.com 
 wrote:

 Hi:

 Without restarting dirsrv possible do that ?


 thx Regards

 barry




 Hello Barry,

 this ldapsearch should list all attributes that needs restart after
 modification:

 $ ldapsearch -D "cn=Directory Manager" -w Secret123 -b cn=config
 nsslapd-requiresrestart

 I don't see nsslapd-security listed so it should be possible to
 change it in
 runtime.

 --
 David Kupka


>>> Yes, I mean ldapmodify.
>>>
>>> Editing dse.ldif while dirsrv is running has no effect because it is
>>> read only at start and written at least before exit.
>>>
>>> If you REALLY need to edit dse.ldif be sure to stop dirsrv then edit it
>>> and start dirsrv again.
>>>
>>> --
>>> David Kupka
>>>
>>
>
>
>
>
-- 
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] can live turn off nsslapd-security: to off ?

[Martin Basti]

On 28.04.2016 08:00, Barry wrote:

NOT work tried ..cannot bind the command 389 or 636 ,,,but telnet work

EOFnsslapd-security: offreplace: nsslapd-securitychangetype: modifydn: 
cn=configldapmodify -h ms -p 636 -D cn="Directory Manager" -w  << EOF


ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)


can you please try to put FQDN name of LDAP server to option -h ?
I have doubts that -h 'ms' is server name

Martin



2016-04-27 19:29 GMT+08:00 >:


thx let me try as i dont want stop dirsrv but live disable nsslapd
security.

2016年4月27日 下午7:26 於 "David Kupka" mailto:dku...@redhat.com>> 寫道：

On 27/04/16 13:15, barry...@gmail.com
 wrote:

Do u meant use ldapmodify?
I tried update the dse.ldif but it will fall back after a
while.

2016年4月27日 下午7:10 於 "David Kupka" mailto:dku...@redhat.com>
>> 寫道：

On 27/04/16 12:48, barry...@gmail.com
 > wrote:

Hi:

Without restarting dirsrv possible do that ?


thx Regards

barry




Hello Barry,

this ldapsearch should list all attributes that needs
restart after
modification:

$ ldapsearch -D "cn=Directory Manager" -w Secret123 -b
cn=config
nsslapd-requiresrestart

I don't see nsslapd-security listed so it should be
possible to change it in
runtime.

--
David Kupka


Yes, I mean ldapmodify.

Editing dse.ldif while dirsrv is running has no effect because
it is read only at start and written at least before exit.

If you REALLY need to edit dse.ldif be sure to stop dirsrv
then edit it and start dirsrv again.

-- 
David Kupka







-- 
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] ca-error: Error setting up ccache for local "host" service using default keytab: Clock skew too great.

[Sumit Bose]

On Wed, Apr 27, 2016 at 07:54:57PM +, Anthony Cheng wrote:
> Hi list,
> 
> I am trying to renew expired certificates following the manual renewal
> procedure here (http://www.freeipa.org/page/IPA_2x_Certificate_Renewal) but
> even with resetting the system/hardware clock to a time before expires, I
> am getting the error "ca-error: Error setting up ccache for local "host"
> service using default keytab: Clock skew too great."

This is a Kerberos error message which it not related to the certificate
lifetime. Please try to make sure that client and server use the same
time.

bye,
Sumit

> 
> With NTP disable and clock reset why would it complain about clock skew and
> how does it even know about the current time?
> 
> [root@test certs]# getcert list
> Number of certificates and requests being tracked: 8.
> Request ID '20111214223243':
> status: MONITORING
> ca-error: Error setting up ccache for local "host" service using
> default keytab: Clock skew too great.
> stuck: no
> key pair storage:
> type=NSSDB,location='/etc/dirsrv/slapd-sample-NET',nickname='Server-Cert',token='NSS
> Certificate DB',pinfile='/etc/dirsrv/slapd-sample-NET//pwdfile.txt'
> certificate:
> type=NSSDB,location='/etc/dirsrv/slapd-sample-NET',nickname='Server-Cert',token='NSS
> Certificate DB'
> CA: IPA
> issuer: CN=Certificate Authority,O=sample.NET
> subject: CN=test.sample.net,O=sample.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: MONITORING
> ca-error: Error setting up ccache for local "host" service using
> default keytab: Clock skew too great.
> 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=sample.NET
> subject: CN=test.sample.net,O=sample.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: MONITORING
> ca-error: Error setting up ccache for local "host" service using
> default keytab: Clock skew too great.
> 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=sample.NET
> subject: CN=test.sample.net,O=sample.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: NEED_CSR_GEN_PIN
> ca-error: Internal error: no response to "
> http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=61&renewal=true&xml=true
> ".
> stuck: yes
> 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=sample.NET
> subject: CN=CA Audit,O=sample.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: NEED_CSR_GEN_PIN
> ca-error: Internal error: no response to "
> http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=60&renewal=true&xml=true
> ".
> stuck: yes
> 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=sample.NET
> subject: CN=OCSP Subsystem,O=sample.NET
> expires: 2017-10-13 14:09:49 UTC
> eku: id-kp-OCSPSigning
> pre-save command: /usr/lib64/ipa/certmonger/stop

Re: [Freeipa-users] ca-error: Error setting up ccache for local "host" service using default keytab: Clock skew too great.

[David Kupka]

On 27/04/16 21:54, Anthony Cheng wrote:

Hi list,

I am trying to renew expired certificates following the manual renewal procedure
here (http://www.freeipa.org/page/IPA_2x_Certificate_Renewal) but even with
resetting the system/hardware clock to a time before expires, I am getting the
error "ca-error: Error setting up ccache for local "host" service using default
keytab: Clock skew too great."

With NTP disable and clock reset why would it complain about clock skew and how
does it even know about the current time?

[root@test certs]# getcert list
Number of certificates and requests being tracked: 8.
Request ID '20111214223243':
 status: MONITORING
 ca-error: Error setting up ccache for local "host" service using
default keytab: Clock skew too great.
 stuck: no
 key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-sample-NET',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-sample-NET//pwdfile.txt'
 certificate:
type=NSSDB,location='/etc/dirsrv/slapd-sample-NET',nickname='Server-Cert',token='NSS
Certificate DB'
 CA: IPA
 issuer: CN=Certificate Authority,O=sample.NET
 subject: CN=test.sample.net ,O=sample.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: MONITORING
 ca-error: Error setting up ccache for local "host" service using
default keytab: Clock skew too great.
 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=sample.NET
 subject: CN=test.sample.net ,O=sample.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: MONITORING
 ca-error: Error setting up ccache for local "host" service using
default keytab: Clock skew too great.
 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=sample.NET
 subject: CN=test.sample.net ,O=sample.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: NEED_CSR_GEN_PIN
 ca-error: Internal error: no response to
"http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=61&renewal=true&xml=true";.
 stuck: yes
 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=sample.NET
 subject: CN=CA Audit,O=sample.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: NEED_CSR_GEN_PIN
 ca-error: Internal error: no response to
"http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert&serial_num=60&renewal=true&xml=true";.
 stuck: yes
 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=sample.NET
 subject: CN=OCSP Subsystem,O=sample.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: NEED_CSR_GEN_PIN
 ca-error: Internal error: no response to
"http:/