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

[Linov Suresh]

Thank you very much Rob.
Let me remove the duplicate certificates and try to renew the certificates
again to see if "*ca-error: Internal error: no response to
"http://caer.teloip.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true
"*."
goes away?


On Fri, Jul 22, 2016 at 2:45 PM, Rob Crittenden  wrote:

> Linov Suresh wrote:
>
>> Could you please verify, if we have set correct trust attributes on the
>> certificates
>>
>> *root@caer ~]# certutil -d /var/lib/pki-ca/alias/ -L*
>>
>> Certificate Nickname Trust
>> Attributes
>>
>>   SSL,S/MIME,JAR/XPI
>>
>> subsystemCert cert-pki-ca   u,u,Pu
>> ocspSigningCert cert-pki-ca u,u,u
>> caSigningCert cert-pki-ca CTu,Cu,Cu
>> subsystemCert cert-pki-ca   u,u,Pu
>> Server-Cert cert-pki-ca u,u,u
>> auditSigningCert cert-pki-ca  u,u,Pu
>> *
>> *
>> *[root@caer ~]# certutil -d /etc/httpd/alias/ -L*
>>
>> Certificate Nickname Trust
>> Attributes
>>
>>   SSL,S/MIME,JAR/XPI
>>
>> ipaCert  u,u,u
>> Server-Certu,u,u
>> TELOIP.NET  IPA CA
>>   CT,C,C
>> ipaCert  u,u,u
>> Signing-Cert   u,u,u
>> Server-Certu,u,u
>>
>> *[root@caer ~]# certutil -d /etc/dirsrv/slapd-TELOIP-NET/ -L*
>>
>> Certificate Nickname Trust
>> Attributes
>>
>>   SSL,S/MIME,JAR/XPI
>>
>> Server-Cert  u,u,u
>> TELOIP.NET  IPA CA
>>   CT,,C
>> Server-Cert  u,u,u
>> [root@caer ~]#
>>
>> *Please note, there are duplicate certificates in CA, HTTP and LDAP
>> directory, subsystemCert cert-pki-ca, ipaCert  and Server-Cert. I was
>> wondering if we need to remove these duplicate certificates? *
>>
>
> Yeah you should remove the duplicate certs, they seem to cause problems
> with dogtag at least (certmonger _should_ handle this automatically, we'll
> be looking into it soonish).
>
> To remove the duplicate cert:
>
> 1. Shutdown the service
> 2. Back up the NSS database
> 3. certutil -L -d /path/to/db -n  -a > somefile
> 4. split somefile into separate files so each file as a BEGIN/END
> certificate
> 5. openssl x509 -text -in -infile somefile1..n
> 6. Pick the one with the most recent issuance date
> 7. You backed up the NSS database, right?
> 8. certutil -D -d /path/to/db -n 
> 9. certutil -A -d /path/to/db -n  -t u,u,u -a -i  somefilex
> 10. Start the service, watch logs for errors
>
> For the trust use whatever the original trust value was.
>
> You don't need the P trust flag on the subsystemCert in the CA, only the
> auditSigningCert.
>
> I doubt the duplicated Server-Cert will be a problem. NSS is supposed to
> deal with this automatically, picking the "most correct" cert to use based
> on the validity period.
>
> rob
>
>
>>
>> On Fri, Jul 22, 2016 at 9:36 AM, Linov Suresh > > wrote:
>>
>> I'm facing another issue now, my kerberos tickets are not renewing,
>>
>> *[root@caer ~]# ipa cert-show 1*
>> ipa: ERROR: Ticket expired
>>
>> *[root@caer ~]# klist*
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: ad...@teloip.net 
>>
>> Valid starting ExpiresService principal
>> 07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net
>> 
>> 07/20/16 14:42:36  07/21/16 14:42:22
>>   HTTP/caer.teloip@teloip.net 
>> 07/21/16 11:40:15  07/21/16 14:42:22
>>   ldap/caer.teloip@teloip.net 
>>
>> I need to manually renew the tickets every day,
>>
>> *[root@caer ~]# kinit admin*
>> Password for ad...@teloip.net :
>> Warning: Your password will expire in 6 days on Thu Jul 28 15:20:15
>> 2016
>>
>> *[root@caer ~]# klist *
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: ad...@teloip.net 
>>
>> Valid starting ExpiresService principal
>> 07/22/16 09:34:52  07/23/16 09:34:49  krbtgt/teloip@teloip.net
>> 
>>
>>
>> On Thu, Jul 21, 2016 at 12:23 PM, Rob Crittenden
>> > wrote:
>>
>> Linov Suresh wrote:
>>
>> The httpd_error log 

Re: [Freeipa-users] change GID not work

[Lukas Slebodnik]

On (22/07/16 10:07), Rob Crittenden wrote:
>Junhe Jian wrote:
>> Hello,
>> 
>> i have a problem to change/set the GID.
>> 
>> I create a new Group with a GID 999 in GUI not work. IPA generate a new
>> GID within the Range.
>
>You are running into https://fedorahosted.org/freeipa/ticket/2886
>
>This is fixed in freeIPA 3.2.
>
>Basically 999 was the "magic" number that IPA used to know when to generate
>an ID value (as opposed to using one requested by the user).
>
>I don't believe there is a workaround for this.
>
IMHO, workaround is to use different GID than 999.
I do not see a reason why group docker could not have gid 998

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] Bypass pre-hashed passwords verification

[Rob Crittenden]

Sébastien Julliot wrote:

Hi Petr,


Thanks for the documentations. I already had followed the steps from the
NIS migration page, it works, but does not solve my problem, which is to
change *already existing users* passwords.

When trying

ipa user-mod testuser --setattr userpassword='{MD5}G3TITOeG1vuPf/IJyhw8WA=='

I get "Pre-Encoded passwords are not valid"


Look at the first link Petr sent you. There is a password sync manager 
setting that should be able to insert pre-hashed passwords.


rob





Le 22/07/2016 à 15:08, Petr Vobornik a écrit :

On 07/22/2016 11:42 AM, Sébastien Julliot wrote:

Hello everyone,

I am currently trying to deploy FreeIPA as the new idm system in my
university but came across a problem I could not solve yet. I need to
bypass the pre-hashed passwords verification, not only on the user creation.

Due to several constraints, our workflow involves periodically (once a
day, currently) receiving an ldif file containing the users up-to-date
informations, (including hashed passwords) and inserting this
informations into the idm. As our goal is to unify users passwords in
the university but do not have access to the higher-level LDAP directly,
we injected this pre-hashed passwords directly into the LDAP until today.

Yet, every attempt I made to update users passwords with pre-hashed
passwords failed for now.

First I tried this (migration mode enabled):

➜  ~ ipa user-add testuser --first=test --last=user --setattr 
userpassword='{MD5}*'

/*OK*/

➜  ~ kinit testuser

kinit: Generic preauthentication failure while getting initial credentials

As expected from the documentation, it does not work :p

I then thought about trying to copy the migration plug-in, and change
the way it retrieves users (from LDIF rather than from an online LDAP
server). Since this plugin is able to  But again, event binding as
Directory Manager, the ipa ldap2 backend method add_entry refuses me (I
tested my code without the userPassword field and the users are
correctly inserted).

Here is my code :

class ldif_importer(ldif.LDIFParser):
 def __init__(self, ldap_backend):
 ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
 self.ldap = ldap_backend

 def handle(self, dn, entry):
 self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))

class my_backend(ipalib.Backend):
 '''Backend to import ldap passwords from ldif'''

 def __init__(self, api):
 ipalib.Backend.__init__(self, api)
 self.ldap = ldap2(self.api)
 self.ldap.connect(bind_dn=DN('cn=Directory Manager'), 
bind_pw='***')

 def parse(self):
 importer = ldif_importer(self.ldap)
 importer.parse()

class my_command(ipalib.Command):
 '''Command calling my_backend to import passwords from ldif'''

 def execute(self, **options):
 '''Implemented against my_backend'''
 self.Backend.my_backend.parse()
 return {'result': 'everything OK'}


Should one of these methods have worked, and I did it incorrectly ?
Otherwise, what would be the lower-impact solution to achieve this ?
(Yes, I understand the security concerns about sending passwords hashes
on the network but this choice does not depend on me)

Many thanks in advance,
Sebastien.


I issue might be that the user has his userPassword migrated but he
doesn't have krbPrincipalKey generated. If kerberos key is missing then
it is automatically generated on successful LDAP bind (it's what
ipa/migration page does)

Additional info which might interest you:
*
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync
* http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords





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

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

[Rob Crittenden]

Linov Suresh wrote:

Could you please verify, if we have set correct trust attributes on the
certificates

*root@caer ~]# certutil -d /var/lib/pki-ca/alias/ -L*

Certificate Nickname Trust
Attributes

  SSL,S/MIME,JAR/XPI

subsystemCert cert-pki-ca   u,u,Pu
ocspSigningCert cert-pki-ca u,u,u
caSigningCert cert-pki-ca CTu,Cu,Cu
subsystemCert cert-pki-ca   u,u,Pu
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca  u,u,Pu
*
*
*[root@caer ~]# certutil -d /etc/httpd/alias/ -L*

Certificate Nickname Trust
Attributes

  SSL,S/MIME,JAR/XPI

ipaCert  u,u,u
Server-Certu,u,u
TELOIP.NET  IPA CA
  CT,C,C
ipaCert  u,u,u
Signing-Cert   u,u,u
Server-Certu,u,u

*[root@caer ~]# certutil -d /etc/dirsrv/slapd-TELOIP-NET/ -L*

Certificate Nickname Trust
Attributes

  SSL,S/MIME,JAR/XPI

Server-Cert  u,u,u
TELOIP.NET  IPA CA
  CT,,C
Server-Cert  u,u,u
[root@caer ~]#

*Please note, there are duplicate certificates in CA, HTTP and LDAP
directory, subsystemCert cert-pki-ca, ipaCert  and Server-Cert. I was
wondering if we need to remove these duplicate certificates? *


Yeah you should remove the duplicate certs, they seem to cause problems 
with dogtag at least (certmonger _should_ handle this automatically, 
we'll be looking into it soonish).


To remove the duplicate cert:

1. Shutdown the service
2. Back up the NSS database
3. certutil -L -d /path/to/db -n  -a > somefile
4. split somefile into separate files so each file as a BEGIN/END 
certificate

5. openssl x509 -text -in -infile somefile1..n
6. Pick the one with the most recent issuance date
7. You backed up the NSS database, right?
8. certutil -D -d /path/to/db -n 
9. certutil -A -d /path/to/db -n  -t u,u,u -a -i  somefilex
10. Start the service, watch logs for errors

For the trust use whatever the original trust value was.

You don't need the P trust flag on the subsystemCert in the CA, only the 
auditSigningCert.


I doubt the duplicated Server-Cert will be a problem. NSS is supposed to 
deal with this automatically, picking the "most correct" cert to use 
based on the validity period.


rob




On Fri, Jul 22, 2016 at 9:36 AM, Linov Suresh > wrote:

I'm facing another issue now, my kerberos tickets are not renewing,

*[root@caer ~]# ipa cert-show 1*
ipa: ERROR: Ticket expired

*[root@caer ~]# klist*
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ad...@teloip.net 

Valid starting ExpiresService principal
07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net

07/20/16 14:42:36  07/21/16 14:42:22
  HTTP/caer.teloip@teloip.net 
07/21/16 11:40:15  07/21/16 14:42:22
  ldap/caer.teloip@teloip.net 

I need to manually renew the tickets every day,

*[root@caer ~]# kinit admin*
Password for ad...@teloip.net :
Warning: Your password will expire in 6 days on Thu Jul 28 15:20:15 2016

*[root@caer ~]# klist *
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ad...@teloip.net 

Valid starting ExpiresService principal
07/22/16 09:34:52  07/23/16 09:34:49  krbtgt/teloip@teloip.net



On Thu, Jul 21, 2016 at 12:23 PM, Rob Crittenden
> wrote:

Linov Suresh wrote:

The httpd_error log doesn't contain the part where `ipa
cert-show 1` was
run. If it is from the same time.

*I am not sure about that, please see httpd_error when `ipa
cert-show 1`
was run*


The IPA API log isn't going to show much in this case.

Requests to the CA are proxied through IPA. The CA WAR is not
running on tomcat so when Apache tries to proxy the request
tomcat returns a 404, Not Found.

You need to start with the dogtag debug and selftest logs to see
what is going on. The logs are pretty verbose and can be
challenging to read.

rob


[root@caer ~]# *tail -f /var/log/httpd/error_log*
[Thu 

Re: [Freeipa-users] Odd Password Issue Across the realm

[Rob Crittenden]

Auerbach, Steven wrote:

I don't think so.  The sssd service is running on the client server. But it is configured with 
cache_credentials=true.  I also notice a key ipa_server = _srv_, ipa02.<>.local.  
The thing is, that second name does was replaced a number of months ago by a server named 
ipa-r02.<>.local.

Could either of these keys point to a problem?


Like I said, it sounds like it is offline. Given that one of the servers 
doesn't exist makes this even more possible.


You need to check the SSSD logs. See 
https://fedorahosted.org/sssd/wiki/Troubleshooting


You can try killing sssd with SIGUSR2 which will try to put it into 
online mode (see man sssd).


rob



Thanks.


Steven Auerbach
Systems Administrator

State University System of Florida
Board of Governors
325 West Gaines Street, Suite 1625C
Tallahassee, Florida 32399
(850) 245-9592
steven.auerb...@flbog.edu | www.flbog.edu




-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Thursday, July 21, 2016 6:24 PM
To: Auerbach, Steven ; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] Odd Password Issue Across the realm

Auerbach, Steven wrote:

We have our IPA set up as master-master and we have about 25 clients
in realm (including the IPA servers themselves).

We have a single user who changed his unexpired password using the
passwd command logged on to one of the registered clients.

Thereafter, when he logs on to any of the client servers in the realm
with the exception of one, his new password is accepted.  On only one
client server his new password is not accepted.  That client server
will only let him in with a password that was in effect 2 password
changes in the past.

I believe that there is no sync problem between the IPA Masters
because I changed the admin password on one of them (IPA Master)
yesterday and it was available immediately after a logout to sign on
as admin to the other master with the new password.

Are we instructing users with the wrong command for changing an
unexpired password?  If not, where would we turn to rectify this issue
that this one user has with the one IPA client server?


I wonder if sssd on that client is in offline mode.

rob



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

[Freeipa-users] Cannot renew expired certificates in IPA 4.2

[lm gnid]

Hello, as in the link bellow, your help will be appreciated!

https://bugzilla.redhat.com/show_bug.cgi?id=1343796
-- 
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] Unable to add CA on an already configured replica

[pgb205]

Current topology:
ipa-srv1<->ipa-srv2
ipa-srv1 already has CA installed but NOT ipa-srv2.
The reason I would like to add CA on ipa-srv2 is because I want the setup to 
ultimately become ipa-srv2<->ipa-srv2<->ipa-srv3
however I am unable to create gpg replication file on ipa-srv2 (to be used to 
establish replication agreement to ipa-srv3)as I get an error message: 
Certificate operation cannot be completed: Unable to communicate with CMS 
(Internal Server Error)From what I've found gpg can only be created on replica 
with CA installed. 

to install CA I tried the following commandipa-ca-install --skip-conncheck 
./replica-info-ipa-srv2.gpg
This errors out at 
  [8/21]: starting certificate server 
instanceipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart 
the Dogtag instance.See the installation log for details.  [9/21]: importing CA 
chain to RA certificate database  [error] RuntimeError: Unable to retrieve CA 
chain: request failed with HTTP status 500
systemctl status pki-tomcatd@pki-tomcat.service
shows the pki service is running, surprisingly.
but it's still not listed in ipactl status output

further attempts to install are halted with error : CA is already installed on 
this system and I have to manually delete everything with:
pkidestroy -s CA -i pki-tomcat 1003  rm -rf /var/log/pki/pki-tomcat 1004  rm 
-rf /etc/sysconfig/pki-tomcat 1005  rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat 
1006  rm -rf /var/lib/pki/pki-tomcat 1007  rm -rf /etc/pki/pki-tomcat

in error logs the one message that stands out is:500 internal server error. 
which repeats multiple times at the end of log file.
Please suggest on what can be done in this situation.
PS: regarding pkidestroy and pkiremove commands. What is the difference or does 
pkidestroy superceeds pkiremove.Alexander B suggests pkiremove in one of his 
older posts and 'yum whatprovides pkiremove' also suggests that it should be 
available.-- 
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] Question DNS

[Günther J . Niederwimmer]

Hello List,

what is the best way to include a local DNS Server?

Can I configure on a IPA DNS Server (extern) views for a internal  DNS without 
problems ?

Is the named Configuration is overwritten by Updates or other ?

I have read now much FreeIPA Doc's but found nothing for this Problem ?
-- 
mit freundlichen Grüßen / best regards,

  Günther J. Niederwimmer

-- 
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] Replicating users/groups from AD

[Simo Sorce]

On Fri, 2016-07-22 at 09:59 -0500, Alston, David wrote:
> Greetings!
> 
>  I realize that FreeIPA is supposed to be setup as master of its
> own domain, but are there any plans to continue the account
> replication functionality that has already been in FreeIPA?  I had
> heard rumor that it would be possible to have FreeIPA and Active
> Directory coexist in the same domain in some release in the future.
> Am I waiting for a feature that will never come?

Hi David,
in order to respond to your question an idea of what are your
expectations would is needed.

If by Domain you mean "AD Domain or Kerberos Realm", the answer is no,
they will never coexists.

If by Domain you mean DNS Domain read then FreeIPA can work in the same
domain as AD but only if you do not care for them interacting (at the
kerberos level, no trusts, no SSO).
You can basically have only one association between a DNS domain and a
Realm, and a DNS domain is either going to be associated to the AD
Domain server or to the IPA Domain.

Synchronization, however is a completely unrelated topic, and I can't
give you an answer on that side as I do not understand how it would
relate to the coexistence of FreeIPA and AD in a single DNS domain.   

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] Replicating users/groups from AD

[Alston, David]

Greetings!

 I realize that FreeIPA is supposed to be setup as master of its own 
domain, but are there any plans to continue the account replication 
functionality that has already been in FreeIPA?  I had heard rumor that it 
would be possible to have FreeIPA and Active Directory coexist in the same 
domain in some release in the future.  Am I waiting for a feature that will 
never come?

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

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

[Linov Suresh]

   I agree with you Jakub, I will start separate thread for separate
   issues.


On Fri, Jul 22, 2016 at 10:31 AM, Jakub Hrozek  wrote:

> On Fri, Jul 22, 2016 at 09:36:27AM -0400, Linov Suresh wrote:
> > I'm facing another issue now, my kerberos tickets are not renewing,
>
> In general I think it's better to start separate threads about separate
> issues. That way people who only scan the subject lines can see if this
> thread is something they can help with :)
>
> >
> > *[root@caer ~]# ipa cert-show 1*
> > ipa: ERROR: Ticket expired
> >
> > *[root@caer ~]# klist*
> > Ticket cache: FILE:/tmp/krb5cc_0
> > Default principal: ad...@teloip.net
> >
> > Valid starting ExpiresService principal
> > 07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net
> > 07/20/16 14:42:36  07/21/16 14:42:22  HTTP/caer.teloip@teloip.net
> > 07/21/16 11:40:15  07/21/16 14:42:22  ldap/caer.teloip@teloip.net
> >
> > I need to manually renew the tickets every day,
> >
> > *[root@caer ~]# kinit admin*
> > Password for ad...@teloip.net:
> > Warning: Your password will expire in 6 days on Thu Jul 28 15:20:15 2016
> >
> > *[root@caer ~]# klist *
> > Ticket cache: FILE:/tmp/krb5cc_0
> > Default principal: ad...@teloip.net
> >
> > Valid starting ExpiresService principal
> > 07/22/16 09:34:52  07/23/16 09:34:49  krbtgt/teloip@teloip.net
>
> The first thing to keep in mind is that SSSD only renews tickets it
> 'knows about', so tickets that were acquired through SSSD, not directly
> with kinit.
>
> For options about renewing SSSD-acquired tickets, see man sssd-krb5 and
> search for renew.
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

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

[Jakub Hrozek]

On Fri, Jul 22, 2016 at 09:36:27AM -0400, Linov Suresh wrote:
> I'm facing another issue now, my kerberos tickets are not renewing,

In general I think it's better to start separate threads about separate
issues. That way people who only scan the subject lines can see if this
thread is something they can help with :)

> 
> *[root@caer ~]# ipa cert-show 1*
> ipa: ERROR: Ticket expired
> 
> *[root@caer ~]# klist*
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: ad...@teloip.net
> 
> Valid starting ExpiresService principal
> 07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net
> 07/20/16 14:42:36  07/21/16 14:42:22  HTTP/caer.teloip@teloip.net
> 07/21/16 11:40:15  07/21/16 14:42:22  ldap/caer.teloip@teloip.net
> 
> I need to manually renew the tickets every day,
> 
> *[root@caer ~]# kinit admin*
> Password for ad...@teloip.net:
> Warning: Your password will expire in 6 days on Thu Jul 28 15:20:15 2016
> 
> *[root@caer ~]# klist *
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: ad...@teloip.net
> 
> Valid starting ExpiresService principal
> 07/22/16 09:34:52  07/23/16 09:34:49  krbtgt/teloip@teloip.net

The first thing to keep in mind is that SSSD only renews tickets it
'knows about', so tickets that were acquired through SSSD, not directly
with kinit.

For options about renewing SSSD-acquired tickets, see man sssd-krb5 and
search for renew.

-- 
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] Bypass pre-hashed passwords verification

[Sébastien Julliot]

Hi Petr,


Thanks for the documentations. I already had followed the steps from the
NIS migration page, it works, but does not solve my problem, which is to
change *already existing users* passwords.

When trying

ipa user-mod testuser --setattr userpassword='{MD5}G3TITOeG1vuPf/IJyhw8WA=='

I get "Pre-Encoded passwords are not valid"



Le 22/07/2016 à 15:08, Petr Vobornik a écrit :
> On 07/22/2016 11:42 AM, Sébastien Julliot wrote:
>> Hello everyone,
>>
>> I am currently trying to deploy FreeIPA as the new idm system in my
>> university but came across a problem I could not solve yet. I need to
>> bypass the pre-hashed passwords verification, not only on the user creation.
>>
>> Due to several constraints, our workflow involves periodically (once a
>> day, currently) receiving an ldif file containing the users up-to-date
>> informations, (including hashed passwords) and inserting this
>> informations into the idm. As our goal is to unify users passwords in
>> the university but do not have access to the higher-level LDAP directly,
>> we injected this pre-hashed passwords directly into the LDAP until today.
>>
>> Yet, every attempt I made to update users passwords with pre-hashed
>> passwords failed for now.
>>
>> First I tried this (migration mode enabled):
>>
>> ➜  ~ ipa user-add testuser --first=test --last=user --setattr 
>> userpassword='{MD5}*'
>>
>> /*OK*/
>>
>> ➜  ~ kinit testuser
>>
>> kinit: Generic preauthentication failure while getting initial credentials
>>
>> As expected from the documentation, it does not work :p
>>
>> I then thought about trying to copy the migration plug-in, and change
>> the way it retrieves users (from LDIF rather than from an online LDAP
>> server). Since this plugin is able to  But again, event binding as
>> Directory Manager, the ipa ldap2 backend method add_entry refuses me (I
>> tested my code without the userPassword field and the users are
>> correctly inserted).
>>
>> Here is my code :
>>
>> class ldif_importer(ldif.LDIFParser):
>> def __init__(self, ldap_backend):
>> ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
>> self.ldap = ldap_backend
>>
>> def handle(self, dn, entry):
>> self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))
>>
>> class my_backend(ipalib.Backend):
>> '''Backend to import ldap passwords from ldif'''
>>
>> def __init__(self, api):
>> ipalib.Backend.__init__(self, api)
>> self.ldap = ldap2(self.api)
>> self.ldap.connect(bind_dn=DN('cn=Directory Manager'), 
>> bind_pw='***')
>>
>> def parse(self):
>> importer = ldif_importer(self.ldap)
>> importer.parse()
>>
>> class my_command(ipalib.Command):
>> '''Command calling my_backend to import passwords from ldif'''
>>
>> def execute(self, **options):
>> '''Implemented against my_backend'''
>> self.Backend.my_backend.parse()
>> return {'result': 'everything OK'}
>>
>>
>> Should one of these methods have worked, and I did it incorrectly ?
>> Otherwise, what would be the lower-impact solution to achieve this ?
>> (Yes, I understand the security concerns about sending passwords hashes
>> on the network but this choice does not depend on me)
>>
>> Many thanks in advance,
>> Sebastien.
>>
> I issue might be that the user has his userPassword migrated but he
> doesn't have krbPrincipalKey generated. If kerberos key is missing then
> it is automatically generated on successful LDAP bind (it's what
> ipa/migration page does)
>
> Additional info which might interest you:
> *
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync
> * http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
>

-- 
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] SSSD with LDAP not showing secondary groups

[Jakub Hrozek]

On Fri, Jul 22, 2016 at 03:04:01PM +0100, Peter Pakos wrote:
> Jakub Hrozek wrote:
> 
> > I'm glad it works now, but why did you choose to use the LDAP back end
> > over the IPA back end? By using LDAP, you gain the ability to not enroll
> > clients with ipa-client-install, but you loose the ease of
> > manageability, HBAC, easy SUDO integration, not to mention you need to
> > put passwords into the config file..
> >
> > Well, we wanted a quick solution for migrating all our servers (a mixture
> of Centos, Debian, SLES, Ubuntu) from using SSSD with an old LDAP server to
> auth against FreeIPA. Since we have all our servers puppetized and using
> sudoers files, it was the best approach I could think of.
> 
> Can you think of a better way of tackling this?
> 
> Now that the dust settles down after the migration, we started enrolling
> infrastructure servers to FreeIPA using ipa-client-install.

Ah, sorry, if you are going through a migration, then it's understandable.

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

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

[Linov Suresh]

Could you please verify, if we have set correct trust attributes on the
certificates

*root@caer ~]# certutil -d /var/lib/pki-ca/alias/ -L*

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

subsystemCert cert-pki-ca   u,u,Pu
ocspSigningCert cert-pki-ca u,u,u
caSigningCert cert-pki-ca CTu,Cu,Cu
subsystemCert cert-pki-ca   u,u,Pu
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca  u,u,Pu

*[root@caer ~]# certutil -d /etc/httpd/alias/ -L*

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

ipaCert  u,u,u
Server-Certu,u,u
TELOIP.NET IPA CA  CT,C,C
ipaCert  u,u,u
Signing-Cert   u,u,u
Server-Certu,u,u

*[root@caer ~]# certutil -d /etc/dirsrv/slapd-TELOIP-NET/ -L*

Certificate Nickname Trust
Attributes

 SSL,S/MIME,JAR/XPI

Server-Cert  u,u,u
TELOIP.NET IPA CACT,,C
Server-Cert  u,u,u
[root@caer ~]#

*Please note, there are duplicate certificates in CA, HTTP and LDAP
directory, subsystemCert cert-pki-ca, ipaCert  and Server-Cert. I was
wondering if we need to remove these duplicate certificates? *


On Fri, Jul 22, 2016 at 9:36 AM, Linov Suresh 
wrote:

> I'm facing another issue now, my kerberos tickets are not renewing,
>
> *[root@caer ~]# ipa cert-show 1*
> ipa: ERROR: Ticket expired
>
> *[root@caer ~]# klist*
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: ad...@teloip.net
>
> Valid starting ExpiresService principal
> 07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net
> 07/20/16 14:42:36  07/21/16 14:42:22  HTTP/caer.teloip@teloip.net
> 07/21/16 11:40:15  07/21/16 14:42:22  ldap/caer.teloip@teloip.net
>
> I need to manually renew the tickets every day,
>
> *[root@caer ~]# kinit admin*
> Password for ad...@teloip.net:
> Warning: Your password will expire in 6 days on Thu Jul 28 15:20:15 2016
>
> *[root@caer ~]# klist *
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: ad...@teloip.net
>
> Valid starting ExpiresService principal
> 07/22/16 09:34:52  07/23/16 09:34:49  krbtgt/teloip@teloip.net
>
>
> On Thu, Jul 21, 2016 at 12:23 PM, Rob Crittenden 
> wrote:
>
>> Linov Suresh wrote:
>>
>>> The httpd_error log doesn't contain the part where `ipa cert-show 1` was
>>> run. If it is from the same time.
>>>
>>> *I am not sure about that, please see httpd_error when `ipa cert-show 1`
>>> was run*
>>>
>>
>> The IPA API log isn't going to show much in this case.
>>
>> Requests to the CA are proxied through IPA. The CA WAR is not running on
>> tomcat so when Apache tries to proxy the request tomcat returns a 404, Not
>> Found.
>>
>> You need to start with the dogtag debug and selftest logs to see what is
>> going on. The logs are pretty verbose and can be challenging to read.
>>
>> rob
>>
>>
>>> [root@caer ~]# *tail -f /var/log/httpd/error_log*
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: WSGI
>>> wsgi_dispatch.__call__:
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: WSGI
>>> xmlserver_session.__call__:
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: found session cookie_id =
>>> bc2c7ed0eccd840dc266efaf9ece913c
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: found session data in
>>> cache with id=bc2c7ed0eccd840dc266efaf9ece913c
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG:
>>> xmlserver_session.__call__: session_id=bc2c7ed0eccd840dc266efaf9ece913c
>>> start_timestamp=2016-07-21T11:58:54 access_timestamp=2016-07-21T12:01:21
>>> expiration_timestamp=2016-07-21T12:18:54
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: storing ccache data into
>>> file "/var/run/ipa_memcached/krbcc_13554"
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: get_credential_times:
>>> principal=HTTP/caer.teloip@teloip.net
>>> , authtime=07/21/16 10:31:46,
>>> starttime=07/21/16 10:43:26, endtime=07/22/16 10:31:44,
>>> renew_till=12/31/69 19:00:00
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: get_credential_times:
>>> principal=HTTP/caer.teloip@teloip.net
>>> , authtime=07/21/16 10:31:46,
>>>
>>> starttime=07/21/16 10:43:26, endtime=07/22/16 10:31:44,
>>> renew_till=12/31/69 19:00:00
>>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: KRB5_CCache
>>> 

Re: [Freeipa-users] sssd shows deleted users as well

[Rakesh Rajasekharan]

under the "configure global security part" of jenkins, we can specify how
jenkins will fetch users for authentication. One option is
"Unix user/group database" . wherein, it will do a getent passwd and fetch
users from there.
Other is to specify ldap.
There are few other ways as well but haven't explored it yet.

Thanks
Rakesh


On Fri, Jul 22, 2016 at 6:54 PM, Jakub Hrozek  wrote:

> On Fri, Jul 22, 2016 at 06:17:32PM +0530, Rakesh Rajasekharan wrote:
> > My specific requirement for having "enumerate=TRUE" was , we have a build
> > server with the jenkins set up.
> > And for authentication jenkins tries to get the localusers on the system.
>
> I'm not sure what you mean by localusers, but does Jenkins really use
> some sort of interface that lists all users through the system
> interface? IIRC Jenkins is written in Java, so I would expect some
> native Java connector instead..
>
> >
> > I should be able to get through that by configuring Jenkins to use LDAP
> > instead of the local users.
> >
> > But  are there any other reasons for recommending against
> "enumerate=TRUE",
> > i recall reading somewhere as well not to use this specific setting.
>
> - performance
> - in general (because it's not the default and few people use
>   enumeration), less tested than the defaul
> - idviews don't work
> - trusted AD users can't be enumerated at all
>
-- 
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] change GID not work

[Rob Crittenden]

Junhe Jian wrote:

Hello,

i have a problem to change/set the GID.

I create a new Group with a GID 999 in GUI not work. IPA generate a new
GID within the Range.


You are running into https://fedorahosted.org/freeipa/ticket/2886

This is fixed in freeIPA 3.2.

Basically 999 was the "magic" number that IPA used to know when to 
generate an ID value (as opposed to using one requested by the user).


I don't believe there is a workaround for this.

rob

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

Re: [Freeipa-users] SSSD with LDAP not showing secondary groups

[Peter Pakos]

Jakub Hrozek wrote:

> I'm glad it works now, but why did you choose to use the LDAP back end
> over the IPA back end? By using LDAP, you gain the ability to not enroll
> clients with ipa-client-install, but you loose the ease of
> manageability, HBAC, easy SUDO integration, not to mention you need to
> put passwords into the config file..
>
> Well, we wanted a quick solution for migrating all our servers (a mixture
of Centos, Debian, SLES, Ubuntu) from using SSSD with an old LDAP server to
auth against FreeIPA. Since we have all our servers puppetized and using
sudoers files, it was the best approach I could think of.

Can you think of a better way of tackling this?

Now that the dust settles down after the migration, we started enrolling
infrastructure servers to FreeIPA using ipa-client-install.

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

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

[Linov Suresh]

I'm facing another issue now, my kerberos tickets are not renewing,

*[root@caer ~]# ipa cert-show 1*
ipa: ERROR: Ticket expired

*[root@caer ~]# klist*
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ad...@teloip.net

Valid starting ExpiresService principal
07/20/16 14:42:26  07/21/16 14:42:22  krbtgt/teloip@teloip.net
07/20/16 14:42:36  07/21/16 14:42:22  HTTP/caer.teloip@teloip.net
07/21/16 11:40:15  07/21/16 14:42:22  ldap/caer.teloip@teloip.net

I need to manually renew the tickets every day,

*[root@caer ~]# kinit admin*
Password for ad...@teloip.net:
Warning: Your password will expire in 6 days on Thu Jul 28 15:20:15 2016

*[root@caer ~]# klist *
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: ad...@teloip.net

Valid starting ExpiresService principal
07/22/16 09:34:52  07/23/16 09:34:49  krbtgt/teloip@teloip.net


On Thu, Jul 21, 2016 at 12:23 PM, Rob Crittenden 
wrote:

> Linov Suresh wrote:
>
>> The httpd_error log doesn't contain the part where `ipa cert-show 1` was
>> run. If it is from the same time.
>>
>> *I am not sure about that, please see httpd_error when `ipa cert-show 1`
>> was run*
>>
>
> The IPA API log isn't going to show much in this case.
>
> Requests to the CA are proxied through IPA. The CA WAR is not running on
> tomcat so when Apache tries to proxy the request tomcat returns a 404, Not
> Found.
>
> You need to start with the dogtag debug and selftest logs to see what is
> going on. The logs are pretty verbose and can be challenging to read.
>
> rob
>
>
>> [root@caer ~]# *tail -f /var/log/httpd/error_log*
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: WSGI
>> wsgi_dispatch.__call__:
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: WSGI
>> xmlserver_session.__call__:
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: found session cookie_id =
>> bc2c7ed0eccd840dc266efaf9ece913c
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: found session data in
>> cache with id=bc2c7ed0eccd840dc266efaf9ece913c
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG:
>> xmlserver_session.__call__: session_id=bc2c7ed0eccd840dc266efaf9ece913c
>> start_timestamp=2016-07-21T11:58:54 access_timestamp=2016-07-21T12:01:21
>> expiration_timestamp=2016-07-21T12:18:54
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: storing ccache data into
>> file "/var/run/ipa_memcached/krbcc_13554"
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: get_credential_times:
>> principal=HTTP/caer.teloip@teloip.net
>> , authtime=07/21/16 10:31:46,
>> starttime=07/21/16 10:43:26, endtime=07/22/16 10:31:44,
>> renew_till=12/31/69 19:00:00
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: get_credential_times:
>> principal=HTTP/caer.teloip@teloip.net
>> , authtime=07/21/16 10:31:46,
>>
>> starttime=07/21/16 10:43:26, endtime=07/22/16 10:31:44,
>> renew_till=12/31/69 19:00:00
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: KRB5_CCache
>> FILE:/var/run/ipa_memcached/krbcc_13554 endtime=1469197904 (07/22/16
>> 10:31:44)
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG:
>> set_session_expiration_time: duration_type=inactivity_timeout
>> duration=1200 max_age=1469197604 expiration=1469118081.77
>> (2016-07-21T12:21:21)
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: WSGI xmlserver.__call__:
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: Created connection
>> context.ldap2
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: WSGI
>> WSGIExecutioner.__call__:
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: raw: cert_show(u'1')
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: cert_show(u'1')
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: IPA: virtual verify
>> retrieve certificate
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG:
>> ipaserver.plugins.dogtag.ra.get_certificate()
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: https_request
>> 'https://caer.teloip.net:443/ca/agent/ca/displayBySerial'
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: https_request post
>> 'xml=true=1'
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: NSSConnection init
>> caer.teloip.net 
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: Connecting: 10.20.0.75:0
>> 
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG:
>> auth_certificate_callback: check_sig=True is_server=False
>> *.*
>> *.*
>> *.*
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: approved_usage =
>> SSLServer intended_usage = SSLServer
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: cert valid True for
>> "CN=caer.teloip.net ,O=TELOIP.NET
>> "
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: handshake complete, peer
>> = 10.20.0.75:443 
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG:
>> auth_certificate_callback: check_sig=True is_server=False
>> *.*
>> *.*
>> *.*
>> [Thu Jul 21 12:01:21 2016] [error] ipa: DEBUG: 

[Freeipa-users] change GID not work

[Junhe Jian]

Hello,

 

i have a problem to change/set the GID.

I create a new Group with a GID 999 in GUI not work. IPA generate a new GID
within the Range.

In Commandline the same

ipa group-add --gid=999 --desc='Docker Group' docker



Added group "docker"



  Group name: docker

  Description: Docker Group

  GID: 108600033

 

With group-mod the same

ipa group-mod --gid=999 docker

---

Modified group "docker"

---

  Group name: docker

  Description: Docker Group

  GID: 108600034

 

I want set to 999 because the host has the group docker with GID=999

 

I run freeipa 3.0.0 on centos 6.7

 

Can anybody help me?

 

--

Best regards

Junhe

 

 



smime.p7s
Description: S/MIME cryptographic signature
-- 
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] sssd shows deleted users as well

[Jakub Hrozek]

On Fri, Jul 22, 2016 at 06:17:32PM +0530, Rakesh Rajasekharan wrote:
> My specific requirement for having "enumerate=TRUE" was , we have a build
> server with the jenkins set up.
> And for authentication jenkins tries to get the localusers on the system.

I'm not sure what you mean by localusers, but does Jenkins really use
some sort of interface that lists all users through the system
interface? IIRC Jenkins is written in Java, so I would expect some
native Java connector instead..

> 
> I should be able to get through that by configuring Jenkins to use LDAP
> instead of the local users.
> 
> But  are there any other reasons for recommending against "enumerate=TRUE",
> i recall reading somewhere as well not to use this specific setting.

- performance
- in general (because it's not the default and few people use
  enumeration), less tested than the defaul
- idviews don't work
- trusted AD users can't be enumerated at all

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

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

[Jan Karásek]

Hi, 

thanks a lot for help guys. It's working now. I can successfully read POSIX 
attributes from AD. 

Just now I'am storring uidNumber, gidNumber, gecos, loginShell and 
unixHomeDirectory in AD. 

I have trouble with homedir. It's using subdomain_homedir from sssd.conf and 
not reflecting the value of unixHomeDirectory attribute. 

Is there any way to use value from AD not from subdomain_homedir template for 
this parameter ? 

Regards, 
Jan 

From: "Justin Stephenson"  
To: "Jan Karásek" , "Alexander Bokovoy" 
 
Cc: freeipa-users@redhat.com 
Sent: Thursday, July 21, 2016 3:54:25 PM 
Subject: Re: [Freeipa-users] AD trust with POSIX attributes 



Hello, 

You should remove the following from sssd.conf: 



[domain/example.tt] 
debug_level = 7 
ldap_id_mapping = False 
id_provider = ad 

With the AD trust configuration, you do not need to specify any additional 
domain because IPA will contact AD across the trust using the external and 
POSIX groups you created during the trust setup. 

Once done try restarting sssd and removing the /var/lib/sss/db/* cache 

Kind regards, 
Justin Stephenson 

On 07/21/2016 07:56 AM, Jan Karásek wrote: 

BQ_BEGIN

Thank you. 

Now I have IDMU installed and when creating trust, IPA is correctly 
autodetecting the range type: 

Range name: EXAMPLE.TT_id_range 
First Posix ID of the range: 1 
Number of IDs in the range: 20 
Domain SID of the trusted domain: S-1-5-21-4123312533-990676102-3576722756 
Range type: Active Directory trust range with POSIX attributes 

When asking for uid of the AD user: 

[root@ipa1 sssd]# id us...@example.tt 
uid=1392001119( us...@example.tt ) gid=1392001119( us...@example.tt ) 
groups=1392001119( us...@example.tt ),1392000513(domain us...@example.tt 
),97907(external_users) 


... so ID-mapping is still in action. 

According to doc: 

To use existing POSIX attributes, two things must be configured: 


* 
The POSIX attributes must be published to Active Directory's global catalog. - 
done with uidNumber, gidNumber 

* 
ID mapping ( ldap_id_mapping in the Active Directory domain entry) must be 
disabled in SSSD. - done 

Here is my sssd.conf from IPA server. Is there anything else I should do to 
switch off ID-mapping ? 

[domain/a.example.tt] 
debug_level = 7 
cache_credentials = True 
krb5_store_password_if_offline = True 
ipa_domain = a.example.tt 
id_provider = ipa 
auth_provider = ipa 
access_provider = ipa 
ipa_hostname = ipa1.a.example.tt 
chpass_provider = ipa 
ipa_server = ipa1.a.example.tt 
ipa_server_mode = True 
ldap_tls_cacert = /etc/ipa/ca.crt 
#subdomain_inherit = ldap_user_principal 
#ldap_user_principal = nosuchattribute 

[domain/example.tt] 
debug_level = 7 
ldap_id_mapping = False 
id_provider = ad 

[sssd] 
services = nss, sudo, pam, ssh 
config_file_version = 2 
domains = a.example.tt, example.tt 

[nss] 
#debug_level = 5 
#homedir_substring = /home 
enum_cache_timeout = 2 
entry_negative_timeout = 2 


[pam] 
#debug_level = 5 
[sudo] 

[autofs] 

[ssh] 
#debug_level = 4 
[pac] 

#debug_level = 4 
[ifp] 


Regards, 
Jan 

From: "Alexander Bokovoy"  
To: "Jan Karásek"  
Cc: "Justin Stephenson"  , freeipa-users@redhat.com 
Sent: Wednesday, July 20, 2016 6:06:29 PM 
Subject: Re: [Freeipa-users] AD trust with POSIX attributes 

On Wed, 20 Jul 2016, Jan Karásek wrote: 
>Hi, 
> 
>thank you. 
> 
>ldapsearch reply: 
> 
>search: 2 
>result: 32 No such object 
>matchedDN: CN=RpcServices,CN=System,DC=rwe,DC=tt 
>text: 208D: NameErr: DSID-03100238, problem 2001 (NO_OBJECT), data 0, best 
>match of: 
>'CN=RpcServices,CN=System,DC=rwe,DC=tt' 
> 
>actually when I look under the CN=RpcServices,CN=System,DC=rwe,DC=tt - it is 
>empty. 
> 
>Do I missed to set something on the AD site ? 
Yes. You need to setup IDMU. However, in Windows Server 2016 Microsoft 
removed IDMU tools. The LDAP schema will stay but there will 
be no means to visually edit POSIX attributes. 

https://blogs.technet.microsoft.com/activedirectoryua/2016/02/09/identity-management-for-unix-idmu-is-deprecated-in-windows-server/
 



> 
>Thanks, 
>Jan 
> 
> 
> 
> 
> 
> 
> 
>From: "Justin Stephenson"  
>To: "Jan Karásek"  
>Cc: freeipa-users@redhat.com 
>Sent: Wednesday, July 20, 2016 4:09:02 PM 
>Subject: Re: [Freeipa-users] AD trust with POSIX attributes 
> 
> 
> 
>These attributes should be available from port 389 and not the global catalog, 
>please try a command such as: 
> 
>ldapsearch -H ldap://  -D "DOMAIN\Administrator" -W -b 
>"cn=ypservers,cn=ypserv30,cn=rpcservices,CN=System,dc=example,dc=com" 
>msSFU30OrderNumber msSFU30MaxUidNumber msSFU30MaxGidNumber 
> 
>Replacing the root suffix in the search base, the ip-address and bind 
>credentials. 
> 
>Kind regards, 
>Justin Stephenson 
> 
>On 07/20/2016 08:15 AM, Jan Karásek wrote: 
> 
> 
> 
>Hi, 
> 
>thank you for the 

Re: [Freeipa-users] Bypass pre-hashed passwords verification

[Petr Vobornik]

On 07/22/2016 11:42 AM, Sébastien Julliot wrote:
> Hello everyone,
> 
> I am currently trying to deploy FreeIPA as the new idm system in my
> university but came across a problem I could not solve yet. I need to
> bypass the pre-hashed passwords verification, not only on the user creation.
> 
> Due to several constraints, our workflow involves periodically (once a
> day, currently) receiving an ldif file containing the users up-to-date
> informations, (including hashed passwords) and inserting this
> informations into the idm. As our goal is to unify users passwords in
> the university but do not have access to the higher-level LDAP directly,
> we injected this pre-hashed passwords directly into the LDAP until today.
> 
> Yet, every attempt I made to update users passwords with pre-hashed
> passwords failed for now.
> 
> First I tried this (migration mode enabled):
> 
> ➜  ~ ipa user-add testuser --first=test --last=user --setattr 
> userpassword='{MD5}*'
> 
> /*OK*/
> 
> ➜  ~ kinit testuser
> 
> kinit: Generic preauthentication failure while getting initial credentials
> 
> As expected from the documentation, it does not work :p
> 
> I then thought about trying to copy the migration plug-in, and change
> the way it retrieves users (from LDIF rather than from an online LDAP
> server). Since this plugin is able to  But again, event binding as
> Directory Manager, the ipa ldap2 backend method add_entry refuses me (I
> tested my code without the userPassword field and the users are
> correctly inserted).
> 
> Here is my code :
> 
> class ldif_importer(ldif.LDIFParser):
> def __init__(self, ldap_backend):
> ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
> self.ldap = ldap_backend
> 
> def handle(self, dn, entry):
> self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))
> 
> class my_backend(ipalib.Backend):
> '''Backend to import ldap passwords from ldif'''
> 
> def __init__(self, api):
> ipalib.Backend.__init__(self, api)
> self.ldap = ldap2(self.api)
> self.ldap.connect(bind_dn=DN('cn=Directory Manager'), 
> bind_pw='***')
> 
> def parse(self):
> importer = ldif_importer(self.ldap)
> importer.parse()
> 
> class my_command(ipalib.Command):
> '''Command calling my_backend to import passwords from ldif'''
> 
> def execute(self, **options):
> '''Implemented against my_backend'''
> self.Backend.my_backend.parse()
> return {'result': 'everything OK'}
> 
> 
> Should one of these methods have worked, and I did it incorrectly ?
> Otherwise, what would be the lower-impact solution to achieve this ?
> (Yes, I understand the security concerns about sending passwords hashes
> on the network but this choice does not depend on me)
> 
> Many thanks in advance,
> Sebastien.
> 

I issue might be that the user has his userPassword migrated but he
doesn't have krbPrincipalKey generated. If kerberos key is missing then
it is automatically generated on successful LDAP bind (it's what
ipa/migration page does)

Additional info which might interest you:
*
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync
* http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords

-- 
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] CA-less install - problem with CA certificates - PLEASE HELP!

[Peter Pakos]

A massive thank you to Jan Cholasta for handholding me while I was getting
this problem fixed. This is how we did it...

1. List all CA certificates in LDAP directory:

ldapsearch -b cn=certificates,cn=ipa,$basedn

2. Using ldapdelete (or LDAP browser), get rid of all certificates that
shouldn't be there, in my case there were 2 called "CA 1" and "CA 2"

3. On each server, list all certificates in the following databases ($db):

- /etc/httpd/alias/
- /etc/dirsrv/slapd-IPA-YOUR-REALM/
- /etc/pki/nssdb/
- /etc/ipa/nssdb/

certutil -L -d $db

4. On each server, delete duplicated certificates ($nick = Certificate
Nickname) from the above databases. Please note, this step removed both
correct and incorrect certificates:

certutil -D -d $db -n "$nick"

5. We had a conflict between one of our intermediate CA certificates
supplied by Gandi and a system certificate (potentially installed by
ca-certificates package) therefore we had to run the following command on
every server to stop the system cert being loaded into httpd database:

modutil -dbdir /etc/httpd/alias -disable 'Root Certs' -force

6. Lastly, we ran the following command on every server to load correct
certificates into all databases:

ipa-certupdate

At this point we had a fully functioning system again with the correct SSL
certificate chain being served by both httpd and dirsrv services.

Please note, an incorrect CA certificate was re-added to the LDAP directory
later on when I deployed a new node and I had to repeat step 2 before
running ipa-certupdate on the new replica.

Once again, I would like to thank Jan for his input - keep up the good work!

-- 
Kind regards,
 Peter Pakos
-- 
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-less install - problem with CA certificates - PLEASE HELP!

[Peter Pakos]

A massive thank you to Jan Cholasta for handholding me while I was getting
this problem fixed. This is how we did it...

1. List all CA certificates in LDAP directory:

ldapsearch -b cn=certificates,cn=ipa,$basedn

2. Using ldapdelete, get rid of all certificates that shouldn't be there,
in my case there were 2 called "CA 1" and "CA 2"

3. List all certificates in the following databases ($db):
- /etc/httpd/alias/
- /etc/dirsrv/slapd-IPA-YOUR-REALM/
- /etc/pki/nssdb/
- /etc/ipa/nssdb/

certutil -L -d $db

4. Delete incorrect certificates from the above databases:




-- 
Kind regards,
 Peter Pakos
-- 
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] Bypass pre-hashed passwords verification

[Sébastien Julliot]

Hello everyone,

I am currently trying to deploy FreeIPA as the new idm system in my
university but came across a problem I could not solve yet. I need to
bypass the pre-hashed passwords verification, not only on the user creation.

Due to several constraints, our workflow involves periodically (once a
day, currently) receiving an ldif file containing the users up-to-date
informations, (including hashed passwords) and inserting this
informations into the idm. As our goal is to unify users passwords in
the university but do not have access to the higher-level LDAP directly,
we injected this pre-hashed passwords directly into the LDAP until today.

Yet, every attempt I made to update users passwords with pre-hashed
passwords failed for now.

First I tried this (migration mode enabled):

➜  ~ ipa user-add testuser --first=test --last=user --setattr 
userpassword='{MD5}*'

/*OK*/

➜  ~ kinit testuser

kinit: Generic preauthentication failure while getting initial credentials

As expected from the documentation, it does not work :p

I then thought about trying to copy the migration plug-in, and change
the way it retrieves users (from LDIF rather than from an online LDAP
server). Since this plugin is able to  But again, event binding as
Directory Manager, the ipa ldap2 backend method add_entry refuses me (I
tested my code without the userPassword field and the users are
correctly inserted).

Here is my code :

class ldif_importer(ldif.LDIFParser):
def __init__(self, ldap_backend):
ldif.LDIFParser.__init__(self, open('test.ldif', 'rb'))
self.ldap = ldap_backend

def handle(self, dn, entry):
self.ldap.add_entry(self.ldap.make_entry(DN(dn), entry))

class my_backend(ipalib.Backend):
'''Backend to import ldap passwords from ldif'''

def __init__(self, api):
ipalib.Backend.__init__(self, api)
self.ldap = ldap2(self.api)
self.ldap.connect(bind_dn=DN('cn=Directory Manager'), 
bind_pw='***')

def parse(self):
importer = ldif_importer(self.ldap)
importer.parse()

class my_command(ipalib.Command):
'''Command calling my_backend to import passwords from ldif'''

def execute(self, **options):
'''Implemented against my_backend'''
self.Backend.my_backend.parse()
return {'result': 'everything OK'}


Should one of these methods have worked, and I did it incorrectly ?
Otherwise, what would be the lower-impact solution to achieve this ?
(Yes, I understand the security concerns about sending passwords hashes
on the network but this choice does not depend on me)

Many thanks in advance,
Sebastien.



signature.asc
Description: OpenPGP digital signature
-- 
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] sssd shows deleted users as well

[Jakub Hrozek]

On Fri, Jul 22, 2016 at 10:28:30AM +0200, Lukas Slebodnik wrote:
> On (22/07/16 13:25), Rakesh Rajasekharan wrote:
> >Hi,
> >
> >I am running freeipa version 4.2.0 and sssd version 1.13.0
> >
> >I have set "enumerate=True" to show IPA users as well in getent passwd.
> >
> >However, the getent passwd continues to show users that have got deleted as
> >well.
> >
> >Heres my sssd config file
> >[domain/xyz.com]
> >enumerate = TRUE
> >krb5_auth_timeout = 30
> >
> >cache_credentials = True
> >krb5_store_password_if_offline = True
> >ipa_domain = xyz.com
> >id_provider = ipa
> >auth_provider = ipa
> >access_provider = ipa
> >ldap_tls_cacert = /etc/ipa/ca.crt
> >ipa_hostname = 10.16.11.134
> >chpass_provider = ipa
> >ipa_server = _srv_, ipa-master-int.xyz.com
> >dns_discovery_domain = xyz.com
> >[sssd]
> >services = nss, sudo, pam, ssh
> >config_file_version = 2
> >
> >domains = xyz.com
> >[nss]
> >homedir_substring = /home
> >
> >[pam]
> >
> >[sudo]
> >
> >[autofs]
> >
> >[ssh]
> >
> >[pac]
> >
> >[ifp]
> >
> >Is this an expected behaviour or am i missing something in my config
> >
> When user is removed from IPA then it is not automatically removed from sssd.
> SSSD has few levels of caches which are indirectly used by "getent passwd".
> The user or group will be removed after next look-up in IPA which
> is usually after extpiration of entry in sssd cache.

Deleted users are only detected when they are looked up directly or when
a cleanup task is ran, because in order to avoid fetching the whole
directory all the time, enumeration tries to only download entries with
higher lastUSN than seen last time. So as Lukas said, it can be expected
that entries show up.

I think the most important lesson here should be don't use
enumerate=true" :-)

> 
> Another way how to force removing entries from sssd cache is
> to authenticate with user. SSSD fetch latest data from LDAP/IPA
> with each authentication for security reasons.
> 
> You can also invalidate user in sssd cache "sss_cache -u someuser"
> and SSSD will detect removed user in IPA after attempt to refresh data
> in sssd cache.
> 
> 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

-- 
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] FreeIPA and slave MIT slave KDCs

[Petr Spacek]

On 21.7.2016 22:05, Diogenes S. Jesus wrote:
> Hi everyone.
> 
> I'm currently planning on deploying FreeIPA as the Master KDC (among other
> things to leverage from the API and some other built-in features - like
> replicas).
> However I find (correct if I'm wrong) FreeIPA not very modular - therefore
> I would like to know what's the strategy when deploying slave KDCs.
> 
> I've seen this thread
> 
> but I
> don't really want to have a replica - the idea was to deploy a separate box
> only running KDC - since the authentication is delegated to RADIUS for
> Authentication, I don't need to expose LDAP Master to KDC slaves - If yes,
> I would provide a read-only LDAP replica..
> 
> 
> For starters, where is the FreeIPA KDC stash file stored?

AFAIK there is no prior art in setting up MIT KDC slaves. First of all,
FreeIPA does not use stash file and stores master key in LDAP instead.

You can retrieve equivalent of stash file using following command:

$ ipa-getkeytab --retrieve --principal K/M@ -k /tmp/stash.keytab
--binddn='cn=Directory manager' --bindpw=''

*Make sure* that --retrieve option is present otherwise it will destroy your
Kerberos database.

The rest is up to your experimentation. I wish you good luck and please report
your findings back to the mailing list!

-- 
Petr^2 Spacek

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

Re: [Freeipa-users] named-pkcs11 doesn't start after bind update

[Roberto Cornacchia]

Ben and Petr,

Thanks for your inputs, I'll keep an eye on those bug reports.

Roberto

On 22 July 2016 at 09:51, Petr Spacek  wrote:

> On 22.7.2016 04:43, Ben Lipton wrote:
> > I'm not familiar enough with Fedora release engineering to know how this
> gets
> > fixed permanently, but I'll share some investigation I've done.
> >
> > This appears to be due to a change in the selinux-policy-targeted
> package that
> > happened recently. As of the latest version, named-pkcs11 tries to run
> as type
> > named_t instead of unconfined_service_t, but it isn't allowed to read the
> > files from IPA [1]. When I downgraded to the selinux-policy and
> > selinux-policy-targeted packages from [2] I was able to start
> named-pkcs11, so
> > that might be a workaround you can use for now. Ultimately, the patch
> that
> > fixes [3] might need to be backported to F23.
>
> This is being tracked as
> https://bugzilla.redhat.com/show_bug.cgi?id=1357665
>
> Stay tuned.
>
> Petr^2 Spacek
>
> >
> > Ben
> >
> > [1]
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:705): avc:  denied  { read } for
> pid=11616
> > comm="named-pkcs11" name="tokens" dev="dm-0" ino=26318195
> > scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=dir permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:706): avc:  denied  { getattr } for
> > pid=11616 comm="named-pkcs11"
> >
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/token.object"
> > dev="dm-0" ino=609982 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.756:707): avc:  denied  { read write } for
> > pid=11616 comm="named-pkcs11" name="generation" dev="dm-0" ino=731584
> > scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.757:708): avc:  denied  { open } for
> pid=11616
> > comm="named-pkcs11"
> >
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> > 
> > time->Fri Jul 22 04:17:44 2016
> > type=AVC msg=audit(1469153864.757:709): avc:  denied  { lock } for
> pid=11616
> > comm="named-pkcs11"
> >
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> > dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> > tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> >
> > [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=758088
> > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1333106
> >
> > On 07/21/2016 05:51 PM, Roberto Cornacchia wrote:
> >> UPDATE:
> >>
> >> Tried again the whole procedure with ipa-dns-install, and it DOES work
> with
> >> SElinux disable, and still fails with SElinux enabled.
> >>
> >> So the error "Failed to enumerate object store in
> /var/lib/softhsm/tokens/"
> >> makes sense.
> >>
> >> Can someone help me fix it?
> >>
> >> $ ll -Z /var/lib/ipa/dnssec/
> >> total 12
> >> -rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul
> 21
> >> 22:50 softhsm_pin*
> >> drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul
> 21
> >> 22:50 tokens/
> >>
> >>
> >>
> >> On 21 July 2016 at 23:11, Roberto Cornacchia <
> roberto.cornacc...@gmail.com
> >> > wrote:
> >>
> >> - FC23
> >> - IPA 4.2.4
> >>
> >> After a dnf update, bind was updated (no ipa updates),
> >> and named-pkcs11 doesn't start anymore.
> >>
> >>
> >> $ /usr/sbin/named-pkcs11 -d 9 -g
> >> 21-Jul-2016 23:08:50.332 starting BIND
> >> 9.10.3-P4-RedHat-9.10.3-13.P4.fc23  -d 9 -g
> >> 21-Jul-2016 23:08:50.332 built with
> >> '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu'
> >> '--program-prefix=' '--disable-dependency-tracking'
> >> '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
> >> '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share'
> >> '--includedir=/usr/include' '--libdir=/usr/lib64'
> >> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
> >> '--mandir=/usr/share/man' '--infodir=/usr/share/info'
> >> '--with-python=/usr/bin/python3' '--with-libtool'
> >> '--localstatedir=/var' '--enable-threads' '--enable-ipv6'
> >> '--enable-filter-' '--with-pic' '--disable-static'
> >> '--disable-openssl-version-check'
> >> '--includedir=/usr/include/bind9' '--with-tuning=large'
> >> '--with-geoip' '--enable-native-pkcs11'
> >> '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so'
> >> '--with-dlopen=yes' '--with-dlz-ldap=yes'
> >> 

Re: [Freeipa-users] named-pkcs11 doesn't start after bind update

[Petr Spacek]

On 22.7.2016 04:43, Ben Lipton wrote:
> I'm not familiar enough with Fedora release engineering to know how this gets
> fixed permanently, but I'll share some investigation I've done.
> 
> This appears to be due to a change in the selinux-policy-targeted package that
> happened recently. As of the latest version, named-pkcs11 tries to run as type
> named_t instead of unconfined_service_t, but it isn't allowed to read the
> files from IPA [1]. When I downgraded to the selinux-policy and
> selinux-policy-targeted packages from [2] I was able to start named-pkcs11, so
> that might be a workaround you can use for now. Ultimately, the patch that
> fixes [3] might need to be backported to F23.

This is being tracked as
https://bugzilla.redhat.com/show_bug.cgi?id=1357665

Stay tuned.

Petr^2 Spacek

> 
> Ben
> 
> [1]
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.756:705): avc:  denied  { read } for pid=11616
> comm="named-pkcs11" name="tokens" dev="dm-0" ino=26318195
> scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=dir permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.756:706): avc:  denied  { getattr } for 
> pid=11616 comm="named-pkcs11"
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/token.object"
> dev="dm-0" ino=609982 scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.756:707): avc:  denied  { read write } for 
> pid=11616 comm="named-pkcs11" name="generation" dev="dm-0" ino=731584
> scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.757:708): avc:  denied  { open } for pid=11616
> comm="named-pkcs11"
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> time->Fri Jul 22 04:17:44 2016
> type=AVC msg=audit(1469153864.757:709): avc:  denied  { lock } for pid=11616
> comm="named-pkcs11"
> path="/var/lib/ipa/dnssec/tokens/12cfb199-b2fe-d328-0b3a-e644756b73d6/generation"
> dev="dm-0" ino=731584 scontext=system_u:system_r:named_t:s0
> tcontext=unconfined_u:object_r:ipa_var_lib_t:s0 tclass=file permissive=1
> 
> [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=758088
> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1333106
> 
> On 07/21/2016 05:51 PM, Roberto Cornacchia wrote:
>> UPDATE:
>>
>> Tried again the whole procedure with ipa-dns-install, and it DOES work with
>> SElinux disable, and still fails with SElinux enabled.
>>
>> So the error "Failed to enumerate object store in /var/lib/softhsm/tokens/"
>> makes sense.
>>
>> Can someone help me fix it?
>>
>> $ ll -Z /var/lib/ipa/dnssec/
>> total 12
>> -rwxrwx---. 1 ods named unconfined_u:object_r:ipa_var_lib_t:s0   30 Jul 21
>> 22:50 softhsm_pin*
>> drwxrws---. 3 ods named unconfined_u:object_r:ipa_var_lib_t:s0 4096 Jul 21
>> 22:50 tokens/
>>
>>
>>
>> On 21 July 2016 at 23:11, Roberto Cornacchia > > wrote:
>>
>> - FC23
>> - IPA 4.2.4
>>
>> After a dnf update, bind was updated (no ipa updates),
>> and named-pkcs11 doesn't start anymore.
>>
>>
>> $ /usr/sbin/named-pkcs11 -d 9 -g
>> 21-Jul-2016 23:08:50.332 starting BIND
>> 9.10.3-P4-RedHat-9.10.3-13.P4.fc23  -d 9 -g
>> 21-Jul-2016 23:08:50.332 built with
>> '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu'
>> '--program-prefix=' '--disable-dependency-tracking'
>> '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin'
>> '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share'
>> '--includedir=/usr/include' '--libdir=/usr/lib64'
>> '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib'
>> '--mandir=/usr/share/man' '--infodir=/usr/share/info'
>> '--with-python=/usr/bin/python3' '--with-libtool'
>> '--localstatedir=/var' '--enable-threads' '--enable-ipv6'
>> '--enable-filter-' '--with-pic' '--disable-static'
>> '--disable-openssl-version-check'
>> '--includedir=/usr/include/bind9' '--with-tuning=large'
>> '--with-geoip' '--enable-native-pkcs11'
>> '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so'
>> '--with-dlopen=yes' '--with-dlz-ldap=yes'
>> '--with-dlz-postgres=yes' '--with-dlz-mysql=yes'
>> '--with-dlz-filesystem=yes' '--with-dlz-bdb=yes'
>> '--with-gssapi=yes' '--disable-isc-spnego' '--enable-fixed-rrset'
>> '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets'
>> '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu'
>> 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall
>> 

Re: [Freeipa-users] FreeIPA / Change SSL Certificate for Web Server

[Florence Blanc-Renaud]

On 07/22/2016 05:08 AM, Devin Acosta wrote:


I have just installed a newly created FreeIPA server running CentOS 7.2.
I have a (wildcard) SSL Certificate that I want to use for the FreeIPA
Web Management GUI. I tried to follow the directions listed here at the
URL
of https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
however when I run those steps I get the error message:

ipa-server-certinstall -w -d star.linuxstack.cloud.key
star.linuxstack.cloud.crt
Directory Manager password:

Enter private key unlock password:

org.fedorahosted.certmonger.duplicate: Certificate at same location is
already used by request with nickname "20160722021526".

Any ideas? It seems like I need to somehow just get the one installed by
default replaced. I don't see any information on how to just replace it?





Hi Devin,

you may be hitting issue 4785 [1]. When ipa-server-certinstall is run, 
it does not stop tracking the previous server certificate and fails to 
start tracking the new cert.


As a side note, with -w -d you are replacing both the directory server 
certificate and the Web Management GUI certificate. If you only want to 
replace the web cert, you can drop the -d option.


Flo.

[1] https://fedorahosted.org/freeipa/ticket/4785

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