[Freeipa-users] Re: How to Setup FreeIPA Services for Mac OS X 10.12

[Jens Timmerman via FreeIPA-users]

Hi,


On 14/06/2017 18:02, Jason Sherrill via FreeIPA-users wrote:
> Hello All,
>
> I have recently submitted a How/To
> 
>  for
> FreeIPA. I'd very much appreciate any feedback or editing on it- I
> don't want to link to it without a review. Thanks!
>
I used /etc/krb5.conf instead of /Library/Preferences/edu.mit.Kerberos
which also seemed to work,
but I noticed the MacOS client doesn't fall back to tcp, so if udp is
blocked in your network you need to specify

[realms]
EXAMPLE.COM = {
 kdc = tcp/ipa-server.example.com
 admin_server = tcp/ipa-server.example.com
}

to get kinit and changing of an expired password to work (using kinit,
haven't configured my accounts as system accounts yet)
> -- 
>
> *Jason Sherrill*
> Deeplocal Inc. 
> mobile: 412-636-2073 
> office: 412-362-0201 
>
Regards,
Jens Timmerman
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Access issues with SSH/IPA

[john.bowman--- via FreeIPA-users]

You'll have to forgive my ignorance here since I'm still fairly new to IPA and 
fortunately haven't run in to many issues as of yet. 

The three IPA 3.0 servers all have what look to be following conflicts:

$ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
"nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict
# filter: nsds5ReplConflict=*
# requesting: * nsds5ReplConflict
nsds5ReplConflict: namingConflict cn=ipa4-4.domain.tld,cn=masters,cn=ipa,cn
nsds5ReplConflict: namingConflict dnahostname=ipa4-4.domain.tld+dnaportnum=
nsds5ReplConflict: namingConflict cn=ipaservers,cn=hostgroups,cn=accounts,dc=z
nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=domain,dc=tld
nsds5ReplConflict: namingConflict cn=domain,cn=topology,cn=ipa,cn=etc,dc=domain,
nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=domain,dc=tld
nsds5ReplConflict: namingConflict cn=dns administrators,cn=privileges,cn=pbac,
nsds5ReplConflict: namingConflict cn=dns servers,cn=privileges,cn=pbac,dc=domain
nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=domain,dc=tld
nsds5ReplConflict: namingConflict cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=domain,
nsds5ReplConflict: namingConflict cn=ca,cn=topology,cn=ipa,cn=etc,dc=domain,dc=u
nsds5ReplConflict: namingConflict cn=system: add ca,cn=permissions,cn=pbac,dc=
nsds5ReplConflict: namingConflict cn=system: delete ca,cn=permissions,cn=pbac,
nsds5ReplConflict: namingConflict cn=system: modify ca,cn=permissions,cn=pbac,
nsds5ReplConflict: namingConflict cn=system: read cas,cn=permissions,cn=pbac,d
nsds5ReplConflict: namingConflict cn=system: modify dns servers configuration,
nsds5ReplConflict: namingConflict cn=system: read dns servers configuration,cn
nsds5ReplConflict: namingConflict cn=system: add ipa locations,cn=permissions,
nsds5ReplConflict: namingConflict cn=system: modify ipa locations,cn=permissio
nsds5ReplConflict: namingConflict cn=system: read ipa locations,cn=permissions
nsds5ReplConflict: namingConflict cn=system: remove ipa locations,cn=permissio
nsds5ReplConflict: namingConflict cn=system: read locations of ipa servers,cn=
nsds5ReplConflict: namingConflict cn=system: read status of services on ipa se
nsds5ReplConflict: namingConflict cn=system: manage service principals,cn=perm
nsds5ReplConflict: namingConflict cn=system: manage user principals,cn=permiss
nsds5ReplConflict: namingConflict dnahostname=ipa4-4.domain.tld+dnaportnum=

While the IPA 4.4 server shows no conflicts:
$ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
"nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict
# filter: nsds5ReplConflict=*
# requesting: * nsds5ReplConflict

So I would need to delete/modify the conflicts on the IPA 3.0 servers but the 
IPA 4.4 server should be okay, correct?  Is there any impact to running the 
ldapmodify command to remove these conflicts while services are running?  Would 
I need to do this on each of the IPA 3.x servers?

Looking at one of the conflicts on one of the IPA 3.0:
$ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
"cn=domain"
# extended LDIF
#
# LDAPv3
# base  with scope subtree
# filter: cn=domain
# requesting: ALL
#

# domain, topology, ipa, etc, domain.us
dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=domain,dc=tld
cn: domain
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
  entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
 uccessfulauth krblastfailedauth krbloginfailedcount
objectClass: top
objectClass: iparepltopoconf
ipaReplTopoConfRoot: dc=domain,dc=tld
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
 ternalModifyTimestamp

# domain + e8d2f70e-512111e7-9205b5bf-43202000, topology, ipa, etc, domain.us
dn: cn=domain+nsuniqueid=e8d2f70e-512111e7-9205b5bf-43202000,cn=topology,cn=ip
 a,cn=etc,dc=domain,dc=tld
nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
 ternalModifyTimestamp
ipaReplTopoConfRoot: dc=domain,dc=tld
objectClass: top
objectClass: iparepltopoconf
nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
 uccessfulauth krblastfailedauth krbloginfailedcount
nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
  entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
cn: domain

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 2

Would I need to remove the "dn: 
cn=domain+nsuniqueid=e8d2f70e-512111e7-9205b5bf-43202000" entry in this case?  
And do that removal on each server?

Thank you and any help is appreciated!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: replication problem

[Eric Renfro via FreeIPA-users]

So, this problem is still causing me unable to install/build any
replica servers.

Eric


-Original Message-

Date: Tue, 13 Jun 2017 12:11:57 -0400
Subject: Re: [Freeipa-users] Re: replication problem
Cc: Mark Reynolds , Rob Crittenden 
To: Rob Crittenden via FreeIPA-users 
From: Eric Renfro 
In my particular case, I'm not using the client installation prior to
the replica installation. Though I have tried that method as well,
resulting in the very same issues regardless.

I'm using this to do the installation currently:

ipa-replica-install --unattended \
--no-ntp --mkhomedir --skip-conncheck \
--ip-address ip.ad.re.ss \
--principal admin \
--admin-password "redacted" \
--server ipa1.home.ld \
--domain home.ld \
--realm HOME.LD

I'm going to try once again with the client install (that part works),
then promoting that to a replica, using kinit to gain admin privileges
and thus omitting the principal, admin-password, domain and realm
options to the replica-install command.

Eric


-Original Message-

Date: Tue, 13 Jun 2017 11:55:26 -0400
Subject: [Freeipa-users] Re: replication problem
Cc: Eric Renfro , Mark Reynolds , Rob Crittenden 
To: FreeIPA users list 
Reply-to: FreeIPA users list 
From: Rob Crittenden via FreeIPA-users 
Eric Renfro via FreeIPA-users wrote:
> Hmmm..
> 
> Well, in my case specifically, the failed ipa-replica-install does in
> fact have the nsslapd-rootpw entry, however, changing this in a
> recovery
> process does no good during an ipa-replica-install.

I think this is a red herring. The client promotion code happened after
my time but I seem to recall that some magic happens regarding the DM
password so it isn't required during the install. I'm pretty sure that
a
random one is set by the installer during initial configuration and at
the end it is replaced by the DM password in the master it is
replicating from.

So in other words it is expected to not match for some of the
installation.

rob

> Eric
> 
> -Original Message-
> 
> *Date*: Tue, 13 Jun 2017 10:51:13 -0400
> *Subject*: [Freeipa-users] Re: replication problem
> *Cc*: Eric Renfro  >, Adrian HY
> mailto:adrian%20hy%20%3cayeja...@gmail.com%3e>>,
> Mark Reynolds  >
> *To*: FreeIPA users list   org%3e>>
> Reply-to: FreeIPA users list 
> *From*: Mark Reynolds via FreeIPA-users
>   s.fedorahosted.org%3e>>
> 
> 
> On 06/13/2017 10:34 AM, Eric Renfro via FreeIPA-users wrote:
> > Huh.. Well, who'da thunk it. I just literally reported the same
> > kind of
> > trouble I was having, which looks like it matches this same
> > situation,
> > with the ipa-replica-install failing to initiate replication
> > because of
> > Invalid password, because the password for some reason does not
> > seem to
> > be being set.
> 
> Sorry, replication does not use the Directory Manager account. 
> Typically some type of "replication manager" entry is used, and in
> IPA
> I'm pretty sure this account uses kerberos credentials (not a
> password).
> 
> Going back to the Directory Manager   To confirm if the password
> is
> set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under cn=config
> look for "nsslapd-rootpw" if this attribute is missing then it truly
> is
> not set.  If your directory manager account does not have a password,
> or
> there is a password but you don't know what it is, then you can reset
> it
> following this doc:
> 
> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.htm
> l
>  ml>
> 
> > Eric
> > 
> > 
> > -Original Message-
> > 
> > Date: Tue, 13 Jun 2017 09:49:40 -0400
> > Subject: [Freeipa-users] Re: replication problem
> > Cc: FreeIPA users list ,
> > Adrian
> > HY 
> > To: Mark Reynolds 
> > Reply-to: FreeIPA users list 
> > From: Adrian HY via FreeIPA-users  > .org
> > Hi Mark, my problem is during the replica installation. I can't use
> > ldapmodify because cn=directory manager  does not have the password
> > assigned.
> > 
> > Regards.
> > 
> > On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds  > >
> > wrote:
> > > On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
> > > > I think I detected the problem. The error log in the replica
> > > > writes:
> > > > 
> > > > [11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet
> > > > length
> > > > exceeds maximum allowed limit (length=2483849, limit=2097152). 
> > > > Change the nsslapd-maxsasliosize attribute in cn=config to
> > > > increase
> > > > limit.
> > > > [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import
> > > > abandoned
> > > > 
> > > > According this: (https://access.redhat.com/documentation/en-US/
> > > > Red_
> > > > Hat_Directory_Server/8.2/pdf/Configurati

[Freeipa-users] Overcoming hurdles installing freeipa-server on ubuntu 17.10

[David Harvey via FreeIPA-users]

Hope this helps to save some of some time digging. And I know,
freeipa-server on a non LTS release is daft..

apt-get install freeipa-server-trust-ad
#This has been mentioned elsewhere, and it should either be a dependency OR
it's absence should not break things as it currently does

sudo mkdir /etc/krb5.conf.d/
#Apparently this is expected by ipa-server to have been generated by one of
the kerberos packages but is not..

mkdir -p /usr/libexec/ipa
sudo ln -s /usr/lib/ipa/ipa-httpd-kdcproxy
/usr/libexec/ipa/ipa-httpd-kdcproxy

#The last two lines are a pretty dirty hack as I couldn't work out where in
the ipa-server-install the file
/etc/systemd/system/apache2.service.d/ipa.conf is created or updated. This
file has a bad path to ipa-httpd-kdcproxy so ideally there should be some
logic to check where it is before defining a path to it.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Apache authentication with Kerberos to IPA

[Ivars Strazdiņš via FreeIPA-users]

Hi,
my question is not directly related to IPA, but since IPA provides underlying 
authentication services, I think it almost fits here.
I have an Apache WebDAV server that authenticates via Kerberos to IPA server.
Related configuration in Apache is:

AuthTypeKerberos
# Essential for Windows clients to connect
KrbMethodNegotiate  Off
KrbMethodK5Passwd   On
KrbAuthRealms   REALM
Krb5KeyTab  /etc/httpd/conf/krb5.keytab
KrbServiceName  HTTP
Require valid-user

I can login with IPA username (i.e. user) and user@REALM
But I also need to login with e-mail, as user@domain, which does not work.
“domain" equals “REALM", but, naturally, domain is lowercase and REALM is 
uppercase.

I could not find any simple solution so far. I thought I could manipulate 
username supplied by user and I tried to play with /etc/krb5.conf, by adding 
auth_to_local statements, as below:

[realms]
  REALM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
# experimenting to convert to uppercase
auth_to_local  = RULE:[1:$1@$0](^.*@domain$)s/@domain/@REALM/
auth_to_local  = DEFAULT
  }

But this doesn’t work and it seems that it is not even tried by Apache/Kerberos.

Could you suggest any other solution if this is possible to achieve at all?
One other way that might work is via Apache module mod_map_user, but I could 
not compile it on Centos7.

Thanks for you time and kind regards,
Ivars

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Access issues with SSH/IPA

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 15, 2017 at 01:07:27PM -, john.bowman--- via FreeIPA-users 
wrote:
> You'll have to forgive my ignorance here since I'm still fairly new to IPA 
> and fortunately haven't run in to many issues as of yet. 
> 
> The three IPA 3.0 servers all have what look to be following conflicts:
> 
> $ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
> "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict
> # filter: nsds5ReplConflict=*
> # requesting: * nsds5ReplConflict
> nsds5ReplConflict: namingConflict cn=ipa4-4.domain.tld,cn=masters,cn=ipa,cn
> nsds5ReplConflict: namingConflict dnahostname=ipa4-4.domain.tld+dnaportnum=
> nsds5ReplConflict: namingConflict cn=ipaservers,cn=hostgroups,cn=accounts,dc=z
> nsds5ReplConflict: namingConflict cn=ipaservers,cn=ng,cn=alt,dc=domain,dc=tld
> nsds5ReplConflict: namingConflict 
> cn=domain,cn=topology,cn=ipa,cn=etc,dc=domain,
> nsds5ReplConflict: namingConflict cn=locations,cn=etc,dc=domain,dc=tld
> nsds5ReplConflict: namingConflict cn=dns administrators,cn=privileges,cn=pbac,
> nsds5ReplConflict: namingConflict cn=dns 
> servers,cn=privileges,cn=pbac,dc=domain
> nsds5ReplConflict: namingConflict cn=cas,cn=ca,dc=domain,dc=tld
> nsds5ReplConflict: namingConflict 
> cn=dogtag,cn=custodia,cn=ipa,cn=etc,dc=domain,
> nsds5ReplConflict: namingConflict 
> cn=ca,cn=topology,cn=ipa,cn=etc,dc=domain,dc=u
> nsds5ReplConflict: namingConflict cn=system: add ca,cn=permissions,cn=pbac,dc=
> nsds5ReplConflict: namingConflict cn=system: delete ca,cn=permissions,cn=pbac,
> nsds5ReplConflict: namingConflict cn=system: modify ca,cn=permissions,cn=pbac,
> nsds5ReplConflict: namingConflict cn=system: read cas,cn=permissions,cn=pbac,d
> nsds5ReplConflict: namingConflict cn=system: modify dns servers configuration,
> nsds5ReplConflict: namingConflict cn=system: read dns servers configuration,cn
> nsds5ReplConflict: namingConflict cn=system: add ipa locations,cn=permissions,
> nsds5ReplConflict: namingConflict cn=system: modify ipa locations,cn=permissio
> nsds5ReplConflict: namingConflict cn=system: read ipa locations,cn=permissions
> nsds5ReplConflict: namingConflict cn=system: remove ipa locations,cn=permissio
> nsds5ReplConflict: namingConflict cn=system: read locations of ipa servers,cn=
> nsds5ReplConflict: namingConflict cn=system: read status of services on ipa se
> nsds5ReplConflict: namingConflict cn=system: manage service principals,cn=perm
> nsds5ReplConflict: namingConflict cn=system: manage user principals,cn=permiss
> nsds5ReplConflict: namingConflict dnahostname=ipa4-4.domain.tld+dnaportnum=
> 
> While the IPA 4.4 server shows no conflicts:
> $ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
> "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict
> # filter: nsds5ReplConflict=*
> # requesting: * nsds5ReplConflict

Depends on whether you need to keep the data on the v3 machine and
whether the data on the v4 machine is correct...

But the general guide to managing replication conflicts is:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/ipa-replica-manage.html

> 
> So I would need to delete/modify the conflicts on the IPA 3.0 servers but the 
> IPA 4.4 server should be okay, correct?  Is there any impact to running the 
> ldapmodify command to remove these conflicts while services are running?  
> Would I need to do this on each of the IPA 3.x servers?
> 
> Looking at one of the conflicts on one of the IPA 3.0:
> $ ldapsearch -D "cn=directory manager" -w secret -b "dc=domain,dc=tld" 
> "cn=domain"
> # extended LDIF
> #
> # LDAPv3
> # base  with scope subtree
> # filter: cn=domain
> # requesting: ALL
> #
> 
> # domain, topology, ipa, etc, domain.us
> dn: cn=domain,cn=topology,cn=ipa,cn=etc,dc=domain,dc=tld
> cn: domain
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
>   entryusn krblastsuccessfulauth krblastfailedauth krbloginfailedcount
> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
>  uccessfulauth krblastfailedauth krbloginfailedcount
> objectClass: top
> objectClass: iparepltopoconf
> ipaReplTopoConfRoot: dc=domain,dc=tld
> nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
>  ternalModifyTimestamp
> 
> # domain + e8d2f70e-512111e7-9205b5bf-43202000, topology, ipa, etc, domain.us
> dn: cn=domain+nsuniqueid=e8d2f70e-512111e7-9205b5bf-43202000,cn=topology,cn=ip
>  a,cn=etc,dc=domain,dc=tld
> nsds5ReplicaStripAttrs: modifiersName modifyTimestamp internalModifiersName in
>  ternalModifyTimestamp
> ipaReplTopoConfRoot: dc=domain,dc=tld
> objectClass: top
> objectClass: iparepltopoconf
> nsDS5ReplicatedAttributeListTotal: (objectclass=*) $ EXCLUDE entryusn krblasts
>  uccessfulauth krblastfailedauth krbloginfailedcount
> nsDS5ReplicatedAttributeList: (objectclass=*) $ EXCLUDE memberof idnssoaserial
>   entryusn krblastsuccessfulauth krblastfailedauth krb

[Freeipa-users] Re: Overcoming hurdles installing freeipa-server on ubuntu 17.10

[Robbie Harwood via FreeIPA-users]

David Harvey via FreeIPA-users  writes:

> sudo mkdir /etc/krb5.conf.d/
> #Apparently this is expected by ipa-server to have been generated by one of
> the kerberos packages but is not..

There's a PR open for this in [1].  Since it hasn't merged, though, it's
probably not going to get a backport.

Additionally, after the Stretch release, the Debian maintainers will be
adding /etc/krb5.conf.d behavior to their krb5.

Thanks,
--Robbie

1: 


signature.asc
Description: PGP signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Certificate renewals with external CA

[Rob Crittenden via FreeIPA-users]

Rob Foehl wrote:
> On Fri, 9 Jun 2017, I wrote:
> 
>> In short, that didn't go particularly well at all, which in some ways
>> brings me back to the original as-yet-unanswered deployment question:
>>
>> Is trying to do this with an external CA worth the pain?
> 
> Three attempts at this question, and zero answers...

Things slip through the cracks.

> Can I at least get a yes or no on whether external CA certificate
> renewal has ever been tested when that certificate is nearing expiration?

Yes. I tested this with IPA v3.0. Did it break in between? Possible.

As I pointed out certmonger is unaware of the certificate chain and
focuses only on the cert not-after date and resubmits the CSR to the CA
that issued the certificate originally.

> I just duplicated last week's result using an earlier snapshot of the
> same VM and a renewed CA cert with a 3-day validity.  certmonger ignored
> every other cert that it already renewed once with the original CA;
> whole system is hosed after the original cert expires.  It's probably
> possible to recover by manually replacing every certificate, but I
> haven't had time to try that.

certmonger checks at days 28, 7, 3, 2 and 1 before expiration by default
for certificate expiration so it should have looked at the certs at
least two times, three depending on timing (and really, it's seconds
before expiration). Did you let the system sit for 3 days before things
died? Was anything logged to syslog? Moving time forward a day at a time
is insufficient to test this without restarting certmonger.

Even in a worst-case scenario, where all the certs expire, it is a
fairly straightforward process to get the services back up by going back
in time, renewing the IPA CA then restarting certmonger to renew the
service certificates.

Is it perfect? No. A search of the users forum should make that
apparent. It has been difficult to reproduce the failures because it's
difficult to simulate by moving time around. Several years ago I left
VMs running for months to try to simulate failures and it always worked
for me.

Note too that there is a difference between certmonger and the renewals.
certmonger renews certs but there are helpers that need to fire off to
update information within IPA as well and to distribute updated
certificates to replicas. These scripts were updated significantly since
I wrote them to be much more robust in terms of reliability and logging.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Overcoming hurdles installing freeipa-server on ubuntu 17.10

[Robbie Harwood via FreeIPA-users]

Robbie Harwood via FreeIPA-users 
writes:

> David Harvey via FreeIPA-users  writes:
>
>> sudo mkdir /etc/krb5.conf.d/
>> #Apparently this is expected by ipa-server to have been generated by one of
>> the kerberos packages but is not..
>
> There's a PR open for this in [1].  Since it hasn't merged, though, it's
> probably not going to get a backport.

Probably would help if I included the link:
https://github.com/freeipa/freeipa/pull/623
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Access issues with SSH/IPA

[john.bowman--- via FreeIPA-users]

Which path would be better?  Upgrading sssd on the older machines or attempting 
to delete the ldap entries?   Both eventually?  Does having the namingConflict 
entries pose a threat to the system stability?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: How to Setup FreeIPA Services for Mac OS X 10.12

[Jason Sherrill via FreeIPA-users]

Thank you Lee and Jens!

I've been testing your suggestions and I'll start deploying the changes
next week.

On Thu, Jun 15, 2017 at 6:03 AM, Jens Timmerman via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi,
>
> On 14/06/2017 18:02, Jason Sherrill via FreeIPA-users wrote:
>
> Hello All,
>
> I have recently submitted a How/To
> 
>  for
> FreeIPA. I'd very much appreciate any feedback or editing on it- I don't
> want to link to it without a review. Thanks!
>
> I used /etc/krb5.conf instead of /Library/Preferences/edu.mit.Kerberos
> which also seemed to work,
> but I noticed the MacOS client doesn't fall back to tcp, so if udp is
> blocked in your network you need to specify
>
> [realms]
> EXAMPLE.COM = {
>  kdc = tcp/ipa-server.example.com
>  admin_server = tcp/ipa-server.example.com
> }
>
> to get kinit and changing of an expired password to work (using kinit,
> haven't configured my accounts as system accounts yet)
>
> --
>
> *Jason Sherrill*
> Deeplocal Inc. 
> mobile: 412-636-2073 <%28412%29%20636-2073>
>
> office: 412-362-0201 <%28412%29%20362-0201>
>
> Regards,
> Jens Timmerman
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>


-- 

*Jason Sherrill*
Deeplocal Inc. 
mobile: 412-636-2073 <(412)%20636-2073>
office: 412-362-0201 <(412)%20362-0201>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Certificate renewals with external CA

[Rob Foehl via FreeIPA-users]

On Thu, 15 Jun 2017, Rob Crittenden wrote:


Rob Foehl wrote:

Can I at least get a yes or no on whether external CA certificate
renewal has ever been tested when that certificate is nearing expiration?


Yes. I tested this with IPA v3.0. Did it break in between? Possible.

As I pointed out certmonger is unaware of the certificate chain and
focuses only on the cert not-after date and resubmits the CSR to the CA
that issued the certificate originally.


Thanks for the reply.

certmonger not knowing about the chain is understandable, as is the 
resubmission of each tracked cert to the existing CA.  Doing this results 
in a pile of certs that expire relatively quickly, being tied to the old 
CA, but that's also not surprising -- the surprise is that it only did 
that once, and has since appeared to ignore them all, even after the CA 
was renewed manually and the newly-issued-but-short-lived certs tied to 
the old CA expired.



I just duplicated last week's result using an earlier snapshot of the
same VM and a renewed CA cert with a 3-day validity.  certmonger ignored
every other cert that it already renewed once with the original CA;
whole system is hosed after the original cert expires.  It's probably
possible to recover by manually replacing every certificate, but I
haven't had time to try that.


certmonger checks at days 28, 7, 3, 2 and 1 before expiration by default
for certificate expiration so it should have looked at the certs at
least two times, three depending on timing (and really, it's seconds
before expiration). Did you let the system sit for 3 days before things
died? Was anything logged to syslog? Moving time forward a day at a time
is insufficient to test this without restarting certmonger.


I let the original VM snapshot run for a month straight, renewing the IPA 
CA by hand after the first round of certmonger-initiated renewals with 14 
days til expiration and on the second attempt after expiration.  The first 
attempt used another 30-day cert, the second used a 3-day and was allowed 
to run straight through.  No time jumps while the VM is running, and all 
snapshots with the VM powered off, so it always booted with an accurate 
clock.


certmonger never logged anything after the first renewal cycle on either 
attempt.  A 'getcert list' on the long-running VM shows all of the tracked 
certificates with an expiration date of 2017-06-24, which matches the 
lifetime of the renewed CA cert, but none of the services attempting to 
load or use them are happy.


Now that I poke around some more, here's a wrinkle:

# getcert list -d /etc/httpd/alias -n Server-Cert
Number of certificates and requests being tracked: 8.
Request ID '20170508063315':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS 
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=EXAMPLE.COM
subject: CN=ipa1.example.com,O=EXAMPLE.COM
expires: 2017-06-24 04:32:24 UTC
dns: ipa1.example.com
principal name: HTTP/ipa1.example@example.com
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes

So certmonger thinks it renewed that, and indeed that certificate is now 
tied to the new IPA CA lifetime *and* was renewed a week after the 
original IPA CA renewal on May 24 (even though this was never logged):


# certutil -L -n Server-Cert -d /etc/httpd/alias
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 19 (0x13)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
Validity:
Not Before: Wed May 31 14:52:53 2017
Not After : Sat Jun 24 04:32:24 2017
Subject: "CN=ipa1.example.com,O=EXAMPLE.COM"

But httpd still refuses to start with that NSSDB, and this appears to be 
why:


# certutil -L -n Signing-Cert -d /etc/httpd/alias
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 9 (0x9)
Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
Issuer: "CN=Certificate Authority,O=EXAMPLE.COM"
Validity:
Not Before: Mon May 08 06:33:16 2017
Not After : Wed Jun 07 06:25:53 2017
Subject: "CN=Object Signing Cert,O=EXAMPLE.COM"


Does certmonger know how to replace the entire certificate chain in the 
respective store(s)?


(The third certificate in there, ipaCert / CN=IPA RA, has the same dates 
as the Server-Cert above.)




Even in a worst-case scenario, where all the certs expire, it is a
fairly straightforward process to get the service

[Freeipa-users] Re: Access issues with SSH/IPA

[Jakub Hrozek via FreeIPA-users]

On Thu, Jun 15, 2017 at 05:15:41PM -, john.bowman--- via FreeIPA-users 
wrote:
> Which path would be better?  Upgrading sssd on the older machines or 
> attempting to delete the ldap entries?   

I think you want to fix the server side, upgrading sssd is just a quick
kludge to let you access the systems.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org