[Freeipa-users] Re: Yum-based upgrade causes group lookup failures.

2023-05-15 Thread Jeff Goddard via FreeIPA-users 
" user DN and
>>>> have the groups lookups configured to use the compat tree, I now populate
>>>> groups as expected. Does this mean I have an access permissions issue with
>>>> my service account? Do you have any suggestions on how I can get the
>>>> service account to work again?
>>>>
>>>> Non-working lookup DN config snippets:
>>>>
>>>>  bindDn="uid=$system_account,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com"
>>>>  bindPassword="$password"
>>>>
>>>> Working lookup DN config snippets:
>>>>  bindDn="uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com"
>>>>  bindPassword="$password"
>>>>
>>>> In both cases above this is used as the group DN:
>>>> roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com
>>>>
>>>> Your assistance is greatly appreciated,
>>>>
>>>> Jeff
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, May 9, 2023 at 3:32 AM Florence Blanc-Renaud 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>> I am not familiar with rundeck but from the provided configuration,
>>>>> the application is using the *memberUid* attribute. IPA stores its
>>>>> groups with the member attribute, not memberUid, unless you are using the
>>>>> compat tree. The compat tree is stored below cn=compat,$BASEDN and 
>>>>> provides
>>>>> a virtual view following RFC 2307 instead of RFC 2307bis. For instance:
>>>>> *IPA group entry*
>>>>> $ ldapsearch -LLL -o ldif-wrap=no  -D cn=directory\ manager -w
>>>>> $PASSWORD -b cn=mygroup,cn=groups,*cn=accounts*,dc=ipa,dc=test
>>>>> dn: cn=mygroup,cn=groups,cn=accounts,dc=ipa,dc=test
>>>>> cn: mygroup
>>>>> objectClass: top
>>>>> objectClass: nestedgroup
>>>>> objectClass: ipausergroup
>>>>> objectClass: ipaobject
>>>>> objectClass: groupofnames
>>>>> objectClass: posixgroup
>>>>> objectClass: ipantgroupattrs
>>>>> ipaUniqueID: ff523b2a-ee38-11ed-8374-fa163eaf69aa
>>>>> gidNumber: 205400095
>>>>> ipaNTSecurityIdentifier: S-1-5-21-1166032515-3431855665-2561613534-1095
>>>>> *member: uid=idmuser,cn=users,cn=accounts,dc=ipa,dc=test*
>>>>>
>>>>> *IPA Group entry in the compat tree*
>>>>> $ ldapsearch -LLL -o ldif-wrap=no  -D cn=directory\ manager -w
>>>>> $PASSWORD -b cn=mygroup,cn=groups,*cn=compat*,dc=ipa,dc=test
>>>>> dn: cn=mygroup,cn=groups,cn=compat,dc=ipa,dc=test
>>>>> objectClass: posixGroup
>>>>> objectClass: ipaOverrideTarget
>>>>> objectClass: ipaexternalgroup
>>>>> objectClass: top
>>>>> gidNumber: 205400095
>>>>> *memberUid: idmuser*
>>>>> ipaAnchorUUID::
>>>>> OklQQTppcGEudGVzdDpmZjUyM2IyYS1lZTM4LTExZWQtODM3NC1mYTE2M2VhZjY5YWE=
>>>>> cn: mygroup
>>>>>
>>>>> There were some changes in the compat tree with slapi-nis-0.60.0-1
>>>>> that may explain the different behavior. You can try to use the compat 
>>>>> tree
>>>>> for the groups (replace
>>>>> *roleBaseDn="cn=groups,cn=accounts,dc=my,dc=domain,dc=com"* with
>>>>> *roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com"*) to make
>>>>> sure the right schema is used.
>>>>>
>>>>> flo
>>>>>
>>>>> On Mon, May 8, 2023 at 3:06 PM Jeff Goddard via FreeIPA-users <
>>>>> freeipa-users@lists.fedorahosted.org> wrote:
>>>>>
>>>>>> Hello and thank you for providing such a useful product.
>>>>>>
>>>>>>
>>>>>> We recently used yum to update our freeipa infrastructure and
>>>>>> everything went off without a hitch with the exception of one of our
>>>>>> integrated apps which now cannot determine group membership. We know the
>>>>>> lookup is successful as the user can login but we use group-based ACLs
>>>>>> from freeipa and when the groups are not populated, the users cannot 
>>>>>> access
>>>>>> the rundeck jobs. Nothing on rundeck was changed, the only actions taken
>>>>>> were "yum update" and "yum upgrade" on the freeipa servers. I've reviewed
>>>>>> the configurations and done some troubleshooting but can't find an answer
>>>>>> so I'm reaching out in hopes someone can give me a clue.
>>>>>>
>>>>>> Environment details:
>>>>>>
>>>>>> Server: CentOS Linux release 7.9.2009 (Core)
>>>>>> Freeipa version: 4.6.8-5.el7.centos.12
>>>>>> Problematic app: Rundeck
>>>>>>
>>>>>> Update logs are attached as is the application ladp lookup config and
>>>>>> application login error. Any help is greatly appreciated.
>>>>>>
>>>>>> Jeff
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>>>>> To unsubscribe send an email to
>>>>>> freeipa-users-le...@lists.fedorahosted.org
>>>>>> Fedora Code of Conduct:
>>>>>> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>> List Guidelines:
>>>>>> https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>> List Archives:
>>>>>> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
>>>>>> Do not reply to spam, report it:
>>>>>> https://pagure.io/fedora-infrastructure/new_issue
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: Yum-based upgrade causes group lookup failures.

2023-05-09 Thread Jeff Goddard via FreeIPA-users 
Not that I can see:

  Permission name: System: Read Group Compat Tree
  Granted rights: read, compare, search
  Effective attributes: cn, createtimestamp, entryusn, gidnumber,
memberuid, modifytimestamp, objectclass
  Default attributes: objectclass, memberuid, gidnumber, cn
  Bind rule type: anonymous
  Subtree: dc=my,dc=domain,dc=com
  Target DN: cn=groups,cn=compat,dc=my,dc=domain,dc=com
  Permission flags: V2, MANAGED, SYSTEM

Jeff

On Tue, May 9, 2023 at 10:14 AM Florence Blanc-Renaud 
wrote:

> Hi,
>
> on a standard installation, the compat tree groups should be readable by
> anyone thanks to the permissions "System: Read Group Compat Tree".
> # ipa permission-show "System: Read Group Compat Tree"
>   Permission name: System: Read Group Compat Tree
>   Granted rights: read, search, compare
>   Effective attributes: cn, createtimestamp, entryusn, gidnumber,
> memberuid, modifytimestamp, objectclass
>   Default attributes: memberuid, gidnumber, objectclass, cn
>   Bind rule type: anonymous
>   Subtree: dc=ipa,dc=test
>   Target DN: cn=groups,cn=compat,dc=ipa,dc=test
>   Permission flags: SYSTEM, V2, MANAGED
>
> Was this permission modified on your system?
>
> flo
>
> On Tue, May 9, 2023 at 2:57 PM Jeff Goddard  wrote:
>
>>
>> Flo,
>>
>> Thank you for giving me a pointer. It helped me better design a test
>> scenario where I now can get success but I'm still looking to improve
>> things. Our lookup configuration uses a system account. If I make the
>> changes you suggest, I still see errors/no populated user groups. However
>> if I switch the lookup user DN in the config to a "regular" user DN and
>> have the groups lookups configured to use the compat tree, I now populate
>> groups as expected. Does this mean I have an access permissions issue with
>> my service account? Do you have any suggestions on how I can get the
>> service account to work again?
>>
>> Non-working lookup DN config snippets:
>>  bindDn="uid=$system_account,cn=sysaccounts,cn=etc,dc=my,dc=domain,dc=com"
>>  bindPassword="$password"
>>
>> Working lookup DN config snippets:
>>  bindDn="uid=$userID,cn=users,cn=accounts,dc=my,dc=domain,dc=com"
>>  bindPassword="$password"
>>
>> In both cases above this is used as the group DN:
>> roleBaseDn="cn=groups,cn=compat,dc=my,dc=domain,dc=com
>>
>> Your assistance is greatly appreciated,
>>
>> Jeff
>>
>>
>>
>>
>>
>> On Tue, May 9, 2023 at 3:32 AM Florence Blanc-Renaud 
>> wrote:
>>
>>> Hi,
>>> I am not familiar with rundeck but from the provided configuration, the
>>> application is using the *memberUid* attribute. IPA stores its groups
>>> with the member attribute, not memberUid, unless you are using the compat
>>> tree. The compat tree is stored below cn=compat,$BASEDN and provides a
>>> virtual view following RFC 2307 instead of RFC 2307bis. For instance:
>>> *IPA group entry*
>>> $ ldapsearch -LLL -o ldif-wrap=no  -D cn=directory\ manager -w $PASSWORD
>>> -b cn=mygroup,cn=groups,*cn=accounts*,dc=ipa,dc=test
>>> dn: cn=mygroup,cn=groups,cn=accounts,dc=ipa,dc=test
>>> cn: mygroup
>>> objectClass: top
>>> objectClass: nestedgroup
>>> objectClass: ipausergroup
>>> objectClass: ipaobject
>>> objectClass: groupofnames
>>> objectClass: posixgroup
>>> objectClass: ipantgroupattrs
>>> ipaUniqueID: ff523b2a-ee38-11ed-8374-fa163eaf69aa
>>> gidNumber: 205400095
>>> ipaNTSecurityIdentifier: S-1-5-21-1166032515-3431855665-2561613534-1095
>>> *member: uid=idmuser,cn=users,cn=accounts,dc=ipa,dc=test*
>>>
>>> *IPA Group entry in the compat tree*
>>> $ ldapsearch -LLL -o ldif-wrap=no  -D cn=directory\ manager -w $PASSWORD
>>> -b cn=mygroup,cn=groups,*cn=compat*,dc=ipa,dc=test
>>> dn: cn=mygroup,cn=groups,cn=compat,dc=ipa,dc=test
>>> objectClass: posixGroup
>>> objectClass: ipaOverrideTarget
>>> objectClass: ipaexternalgroup
>>> objectClass: top
>>> gidNumber: 205400095
>>> *memberUid: idmuser*
>>> ipaAnchorUUID::
>>> OklQQTppcGEudGVzdDpmZjUyM2IyYS1lZTM4LTExZWQtODM3NC1mYTE2M2VhZjY5YWE=
>>> cn: mygroup
>>>
>>> There were some changes in the compat tree with slapi-nis-0.60.0-1 that
>>> may explain the different behavior. You can try to use the compat tree for
>>> the groups (replace
>>> *roleBaseDn="cn=groups,cn=accounts,dc=my,dc=domain,dc=com"* with
>>> *roleBaseDn="cn=groups,

[Freeipa-users] Re: Enrollment Administrator role

2020-02-12 Thread Jeff Goddard via FreeIPA-users 
On Wed, Feb 12, 2020 at 1:10 PM Rob Crittenden  wrote:

> Jeff Goddard via FreeIPA-users wrote:
> > Hello again,
> >
> > We're using salt for automation and have created a salt service account
> > for the express permissions of joining machines to our domain. This user
> > has been assigned the "Enrollment Administrator" roll but when
> > attempting to join clients the log output is as follows:
> >
> > Client hostname: ubuntu.domain.com <http://ubuntu.domain.com>
> > Realm: DOMAIN.COM <http://DOMAIN.COM>
> > DNS Domain: domain.com <http://domain.com>
> > IPA Server: server1.domain.com <http://server1.domain.com>
> > BaseDN: dc=domain,dc=com
> >
> > Continue to configure the system with these values? [no]: yes
> > Synchronizing time
> > Configuration of chrony was changed by installer.
> > Attempting to sync time with chronyc.
> > Time synchronization was successful.
> > User authorized to enroll computers: test-join
> > Password for t...@domain.com <mailto:t...@domain.com>:
> > Successfully retrieved CA cert
> > Subject: CN=Certificate Authority,O=DOMAIN.COMIPA environment is
> 4.4
> > Issuer:  CN=Certificate Authority,O=DOMAIN.COM <
> http://DOMAIN.COM>
> > Valid From:  2017-01-26 18:47:36
> > Valid Until: 2037-01-26 18:47:36
> >
> > Joining realm failed: No permission to join this host to the IPA domain.
> >
> >
> > The FreeIPA version is 4.6.5 and its running on Centos 7.7. Can someone
> > assist me in troubleshooting? Is there another pre-defined role or
> > permission that I need to assign?
>
> Does the host already exist in IPA? The Enrollment Administrator role
> allows for enrollment, not host creation. You can add the host add
> capability it just ships with the minimum required.
>
> rob
>
>

Rob,

Thanks for the prompt reply. That was just the thing.

Cheers,

Jeff
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Enrollment Administrator role

2020-02-12 Thread Jeff Goddard via FreeIPA-users 
Hello again,

We're using salt for automation and have created a salt service account for
the express permissions of joining machines to our domain. This user has
been assigned the "Enrollment Administrator" roll but when attempting to
join clients the log output is as follows:

Client hostname: ubuntu.domain.com
Realm: DOMAIN.COM
DNS Domain: domain.com
IPA Server: server1.domain.com
BaseDN: dc=domain,dc=com

Continue to configure the system with these values? [no]: yes
Synchronizing time
Configuration of chrony was changed by installer.
Attempting to sync time with chronyc.
Time synchronization was successful.
User authorized to enroll computers: test-join
Password for t...@domain.com:
Successfully retrieved CA cert
Subject: CN=Certificate Authority,O=DOMAIN.COMIPA environment is 4.4
Issuer:  CN=Certificate Authority,O=DOMAIN.COM
Valid From:  2017-01-26 18:47:36
Valid Until: 2037-01-26 18:47:36

Joining realm failed: No permission to join this host to the IPA domain.


The FreeIPA version is 4.6.5 and its running on Centos 7.7. Can someone
assist me in troubleshooting? Is there another pre-defined role or
permission that I need to assign?

Thanks,

Jeff
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Certificate renewal question

2019-03-26 Thread Jeff Goddard via FreeIPA-users 
Flo,

That seems to have resolved everything. I'll note that in the future CA
renewals are best done on the renewal master and hopefully avoid this
situation.

Thanks,

Jeff

On Tue, Mar 26, 2019 at 11:29 AM Florence Blanc-Renaud 
wrote:

> On 3/26/19 4:04 PM, Jeff Goddard via FreeIPA-users wrote:
> > Flo,
> >
> > Thanks for jumping in. When I run the command on both servers I get
> > different serial numbers. The domain has been made generic in the paste
> > below.
> >
> > Renewal master:
> > Certificate:
> > Data:
> > Version: 3 (0x2)
> > Serial Number: 44 (0x2c)
> > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> > Issuer: "CN=Certificate Authority,O=my.domain.org
> > <http://my.domain.org>"
> > Validity:
> > Not Before: Mon Mar 25 17:46:13 2019
> > Not After : Sun Mar 14 17:46:13 2021
> > Subject: "CN=CA Subsystem,O=my.domain.org <http://my.domain.org
> >"
> > Subject Public Key Info:
> > Public Key Algorithm: PKCS #1 RSA Encryption
> > RSA Public Key:
> > Modulus:
> >
> > Peer (problematic) CA:
> >
> > Certificate:
> > Data:
> > Version: 3 (0x2)
> > Serial Number: 25 (0x19)
> > Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
> > Issuer: "CN=Certificate Authority,O=my.domain.org
> > <http://my.domain.org>"
> > Validity:
> > Not Before: Thu Dec 20 18:23:18 2018
> > Not After : Wed Dec 09 18:23:18 2020
> > Subject: "CN=CA Subsystem,O=my.domain.org <http://my.domain.org
> >"
> > Subject Public Key Info:
> > Public Key Algorithm: PKCS #1 RSA Encryption
> > RSA Public Key:
> > Modulus:
> >
> Hi,
>
> from the output we can see that the cert has been renewed in advance on
> the renewal master. The replica still sees it subsystemCert cert-pki-ca
> as valid (expiration date not reached yet), meaning that you need to
> force its update.
>
> Can you run on the (non-renewal) replica:
> getcert list -n "subsystemCert cert-pki-ca"
> => Note the Request ID
>
> getcert resubmit -i 
>
> and check if it is able to download the cert? On non-renewal master, the
> resubmit command will look for a renewed cert in the LDAP server, below
> cn=ca_renewal,cn=ipa,cn=etc,$BASEDN. This is why Fraser warned you about
> the replication (if replication is broken, the entry may not be updated).
>
> HTH,
> flo
>
> > Jeff
> >
> > On Tue, Mar 26, 2019 at 10:56 AM Florence Blanc-Renaud  > <mailto:f...@redhat.com>> wrote:
> >
> > On 3/26/19 2:12 PM, Jeff Goddard via FreeIPA-users wrote:
> >  > Fraser,
> >  >
> >  > My thanks to both Rob and you for responding. When I check the
> > status of
> >  > the certificate today I see that is is back in the "monitoring"
> > state
> >  > but it has not changed the expiration date and there is a
> ca-error:
> >  > ca-error: Invalid cookie: u''. To confirm, the CA I'm working
> > with is
> >  > not the renewal master. When I check the renewal master for the
> same
> >  > certificate, I see a different expiration date and no errors.
> > Running
> >  > the command ipa-replica-manage list on both servers show the full
> > set of
> >  > 4 masters and no errors. Can someone provide insight on why the
> >  > non-renewal master has a bad date for this certificate and if its
> >  > related to the above error, how to rectify the situation?
> >  >
> > Hi,
> >
> > As I understand, getcert list -n 'subsystemCert cert-pki-ca' is still
> > showing the previous cert.
> >
> > Can you check if the /etc/pki/pki-tomcat/alias database contains the
> > previous or the renewed cert?
> > $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert
> > cert-pki-ca'
> >     You can compare the Serial Number with the one on the renewal
> > master, or
> > the Not before/not after dates. It is possible that certmonger
> > output is
> > wrong although the cert has been renewed and properly downloaded.
> >
> > flo
> >
> >  > Thanks,
> >  >
> >  > Jeff
> >  >
> >  >
> >

[Freeipa-users] Re: Certificate renewal question

2019-03-26 Thread Jeff Goddard via FreeIPA-users 
Flo,

Thanks for jumping in. When I run the command on both servers I get
different serial numbers. The domain has been made generic in the paste
below.

Renewal master:
Certificate:
   Data:
   Version: 3 (0x2)
   Serial Number: 44 (0x2c)
   Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
   Issuer: "CN=Certificate Authority,O=my.domain.org"
   Validity:
   Not Before: Mon Mar 25 17:46:13 2019
   Not After : Sun Mar 14 17:46:13 2021
   Subject: "CN=CA Subsystem,O=my.domain.org"
   Subject Public Key Info:
   Public Key Algorithm: PKCS #1 RSA Encryption
   RSA Public Key:
   Modulus:

Peer (problematic) CA:

Certificate:
   Data:
   Version: 3 (0x2)
   Serial Number: 25 (0x19)
   Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
   Issuer: "CN=Certificate Authority,O=my.domain.org"
   Validity:
   Not Before: Thu Dec 20 18:23:18 2018
   Not After : Wed Dec 09 18:23:18 2020
   Subject: "CN=CA Subsystem,O=my.domain.org"
   Subject Public Key Info:
   Public Key Algorithm: PKCS #1 RSA Encryption
   RSA Public Key:
   Modulus:

Jeff

On Tue, Mar 26, 2019 at 10:56 AM Florence Blanc-Renaud 
wrote:

> On 3/26/19 2:12 PM, Jeff Goddard via FreeIPA-users wrote:
> > Fraser,
> >
> > My thanks to both Rob and you for responding. When I check the status of
> > the certificate today I see that is is back in the "monitoring" state
> > but it has not changed the expiration date and there is a ca-error:
> > ca-error: Invalid cookie: u''. To confirm, the CA I'm working with is
> > not the renewal master. When I check the renewal master for the same
> > certificate, I see a different expiration date and no errors. Running
> > the command ipa-replica-manage list on both servers show the full set of
> > 4 masters and no errors. Can someone provide insight on why the
> > non-renewal master has a bad date for this certificate and if its
> > related to the above error, how to rectify the situation?
> >
> Hi,
>
> As I understand, getcert list -n 'subsystemCert cert-pki-ca' is still
> showing the previous cert.
>
> Can you check if the /etc/pki/pki-tomcat/alias database contains the
> previous or the renewed cert?
> $ certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca'
> You can compare the Serial Number with the one on the renewal master, or
> the Not before/not after dates. It is possible that certmonger output is
> wrong although the cert has been renewed and properly downloaded.
>
> flo
>
> > Thanks,
> >
> > Jeff
> >
> >
> > On Tue, Mar 26, 2019 at 6:17 AM Fraser Tweedale  > <mailto:ftwee...@redhat.com>> wrote:
> >
> > On Mon, Mar 25, 2019 at 01:37:00PM -0400, Rob Crittenden via
> > FreeIPA-users wrote:
> >  > Jeff Goddard via FreeIPA-users wrote:
> >  > > Hello everyone and thanks for providing the FreeIPA platform.
> >  > >
> >  > > I've got a situation where I have 4 FreeIPA peer servers, with
> > 2 of them
> >  > > being CAs with replication configured. These are split into 2
> > physical
> >  > > locations with 1 CA per site. I was testing renewal of the
> >  > > "nickname='subsystemCert cert-pki-ca" certificate in one of my
> > sites by
> >  > > issuing ipa-getcert resubmit -i [cert ID#]. Now this
> > certificate seems
> >  > > to be stuck with a status of CA_Working. Since its been over 4
> > hours
> >  > > since I submitted the request I'm wondering if something went
> > wrong and
> >  > > where I can begin looking to troubleshoot. I tried running
> >  > > ipa-certupdate to sync from the other CA master and it completed
> >  > > successfully. The original certificate was not expired and
> > other than
> >  > > the "CA Working" status there are no apparent problems. The
> > server is
> >  > > version 4.6.4 running on Centos 7.4. Do I have reason to be
> > concerned or
> >  > > is this expected behavior?
> >  >
> >  > Only the CA renewal master actually renews certificates. I'm
> > going to assume
> >  > this particular host is not that which means it is waiting for
> > some other
> >  > host to do the renewal and stuff the updated certificate into a
> > location in
> >  > LDAP which this will eventually pick up and install.
> >  >

[Freeipa-users] Re: Certificate renewal question

2019-03-26 Thread Jeff Goddard via FreeIPA-users 
Fraser,

My thanks to both Rob and you for responding. When I check the status of
the certificate today I see that is is back in the "monitoring" state but
it has not changed the expiration date and there is a ca-error: ca-error:
Invalid cookie: u''. To confirm, the CA I'm working with is not the renewal
master. When I check the renewal master for the same certificate, I see a
different expiration date and no errors. Running the command ipa-replica-manage
list on both servers show the full set of 4 masters and no errors. Can
someone provide insight on why the non-renewal master has a bad date for
this certificate and if its related to the above error, how to rectify the
situation?

Thanks,

Jeff


On Tue, Mar 26, 2019 at 6:17 AM Fraser Tweedale  wrote:

> On Mon, Mar 25, 2019 at 01:37:00PM -0400, Rob Crittenden via FreeIPA-users
> wrote:
> > Jeff Goddard via FreeIPA-users wrote:
> > > Hello everyone and thanks for providing the FreeIPA platform.
> > >
> > > I've got a situation where I have 4 FreeIPA peer servers, with 2 of
> them
> > > being CAs with replication configured. These are split into 2 physical
> > > locations with 1 CA per site. I was testing renewal of the
> > > "nickname='subsystemCert cert-pki-ca" certificate in one of my sites by
> > > issuing ipa-getcert resubmit -i [cert ID#]. Now this certificate seems
> > > to be stuck with a status of CA_Working. Since its been over 4 hours
> > > since I submitted the request I'm wondering if something went wrong and
> > > where I can begin looking to troubleshoot. I tried running
> > > ipa-certupdate to sync from the other CA master and it completed
> > > successfully. The original certificate was not expired and other than
> > > the "CA Working" status there are no apparent problems. The server is
> > > version 4.6.4 running on Centos 7.4. Do I have reason to be concerned
> or
> > > is this expected behavior?
> >
> > Only the CA renewal master actually renews certificates. I'm going to
> assume
> > this particular host is not that which means it is waiting for some other
> > host to do the renewal and stuff the updated certificate into a location
> in
> > LDAP which this will eventually pick up and install.
> >
> As long as replication is working properly ;)
>
> Also just to clarify: each CA server will renew host-specific
> certificates on its own (HTTPS, LDAPS and KDC certificates).  But
> shared certificates (Dogtag system certs and IPA RA) are only
> renewed on the renewal master.
>
> Cheers,
> Fraser
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Certificate renewal question

2019-03-25 Thread Jeff Goddard via FreeIPA-users 
Hello everyone and thanks for providing the FreeIPA platform.

I've got a situation where I have 4 FreeIPA peer servers, with 2 of them
being CAs with replication configured. These are split into 2 physical
locations with 1 CA per site. I was testing renewal of the
"nickname='subsystemCert
cert-pki-ca" certificate in one of my sites by issuing ipa-getcert resubmit
-i [cert ID#]. Now this certificate seems to be stuck with a status of
CA_Working. Since its been over 4 hours since I submitted the request I'm
wondering if something went wrong and where I can begin looking to
troubleshoot. I tried running ipa-certupdate to sync from the other CA
master and it completed successfully. The original certificate was not
expired and other than the "CA Working" status there are no apparent
problems. The server is version 4.6.4 running on Centos 7.4. Do I have
reason to be concerned or is this expected behavior?

Thanks,

Jeff
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Help with webapps and expired passwords

2019-02-06 Thread Jeff Goddard via FreeIPA-users 
Hi,

I find myself in situation described in this thread:
https://serverfault.com/questions/716556/freeipa-ldap-refuse-auth-for-users-with-expired-password
Basically we have enabled the FreeIPA LDAP back end to authenticate our
uses to various web applications (Confluence, jira, rundeck, etc.) as well
as our VPN. What I'm finding is that users with expired passwords are still
able to access all of the services. I see there is an issue in development (
https://pagure.io/freeipa/issue/1539) but it looks to be a complex issue
that doesn't seem prudent to wait for. Does anyone have a script or
pointers on how I can search for expired passwords and disable the user
accounts if they are expired? Or is there another method to accomplish
having users with expired passwords get denied access to VPN and web
services if their password is expired?

Thanks,

Jeff
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Re: Centos update breaks access to samba shares

2019-01-24 Thread Jeff Goddard via FreeIPA-users 
I was able to just bring up a snapshot of the original server and then
update but exclude the samba packages.

On Thu, Jan 24, 2019 at 11:09 AM Jeff Goddard  wrote:

> Hi everyone,
>
> Yesterday I updated our (Centos 7) Freeipa servers and it seems that now
> the samba shares hosted on one of them is no longer accessible. I've done
> some reading and see that authentication now requires the winbind package
> to be running, and in our case it is, but I'm still not able to
> authenticate users on either Windows or Linux. We do not use AD so there
> are no trusts to worry about. Has anyone else experienced this and know a
> solution?
>
> Thanks,
>
> Jeff
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Centos update breaks access to samba shares

2019-01-24 Thread Jeff Goddard via FreeIPA-users 
Hi everyone,

Yesterday I updated our (Centos 7) Freeipa servers and it seems that now
the samba shares hosted on one of them is no longer accessible. I've done
some reading and see that authentication now requires the winbind package
to be running, and in our case it is, but I'm still not able to
authenticate users on either Windows or Linux. We do not use AD so there
are no trusts to worry about. Has anyone else experienced this and know a
solution?

Thanks,

Jeff
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org

[Freeipa-users] Problems with updated ubuntu

2018-02-20 Thread Jeff Goddard via FreeIPA-users 
I'm trying to deploy 2 new VMs which will be docker hosts. Our base
template is ubuntu 16.04 last patched on 1.2.18. The process is to spin up
a new VM from the template and then patch it, assign IP, and add to free
ipa domain - all steps which occurred without error.  However, I'm not able
to ssh into these new servers and also unable to log on as my user from the
console. Here are the errors from auth.log:

Feb 20 15:16:14 docker-prod-03 sshd[1056]: Server listening on 0.0.0.0 port
22.
Feb 20 15:16:14 docker-prod-03 sshd[1056]: Server listening on :: port 22.
Feb 20 15:16:27 docker-prod-03 login[1155]: pam_unix(login:auth): check
pass; user unknown
Feb 20 15:16:27 docker-prod-03 login[1155]: pam_unix(login:auth):
authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser=
rhost=
Feb 20 15:16:27 docker-prod-03 login[1155]: pam_sss(login:auth):
authentication success; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser=
rhost= user=jgoddard
Feb 20 15:16:27 docker-prod-03 login[1155]: pam_unix(login:account): could
not identify user (from getpwnam(jgoddard))
Feb 20 15:16:27 docker-prod-03 login[1155]: Authentication failure

I spooled out a new VM from the template and did not update it, performed
the same tasks (hostname, ip assignment, IPA join), and do not have the
problems. Can I get some assistance in 1) isolating which sets of packages
caused the issue, and 2) reporting a bug if necessary?

Thanks,

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

[Freeipa-users] IPA users and local groups question

2018-02-13 Thread Jeff Goddard via FreeIPA-users 
First off thanks to everyone who makes FreeIPA. Its an awesome product that
we love.

We're working at breaking our application up into micro services and using
docker containers and deployment automation. As part of this I have a
deploy user in IPA and a rundeck server that performs tasks as this user.
However, we need this user to be part of the local docker hosts "docker"
group. Is this something I have to do manually per host? Is it possible to
create a docker IPA group that will substitute for the local docker group
and do it all in IPA? Our IPA version is 4.4. The servers are Centos 7.2
and the clients are ubuntu 16.04 LTS.

Thanks for the insight, references and help,

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

[Freeipa-users] Re: Home directory not being created in log in

2018-01-29 Thread Jeff Goddard via FreeIPA-users 
My servers are centos but here is the script we run.

CENTOS

authconfig --enableldap \
--enableldapauth \
 --ldapserver=servername.internal.com \
--ldapbasedn="cn=users,cn=accounts,dc=internal,dc=com" \
--enablemkhomedir \
--update


On Mon, Jan 29, 2018 at 4:51 PM, Kristian Petersen 
wrote:

> Oddjobd is installed and is enabled and running at least.  Where would you
> configure it that I could check?
>
> oddjobd.service - privileged operations for unprivileged applications
>   Loaded: loaded (/usr/lib/systemd/system/oddjobd.service; enabled;
> vendor preset: disabled)
>   Active: active (running) since Mon 2018-01-29 12:43:23 MST; 44min ago
> Main PID: 1683 (oddjobd)
>   CGroup: /system.slice/oddjobd.service
>   └─1683 /usr/sbin/oddjobd -n -p /var/run/oddjobd.pid -t 300
>
>
> On Mon, Jan 29, 2018 at 1:25 PM, Jeff Goddard 
> wrote:
>
>> Sounds like oddjobd isn't installed/configured.
>>
>> On Mon, Jan 29, 2018 at 3:23 PM, Kristian Petersen via FreeIPA-users <
>> freeipa-users@lists.fedorahosted.org> wrote:
>>
>>> I am trying to set up a workstation running RHEL 7 with Gnome graphical
>>> environment.  I have enrolled this machine as a client in IPA using the
>>> --mkhomedir flag, however, the home directory is not being created when I
>>> log in.  Because the home directory doesn't get created at log in GDM kicks
>>> me back out to the log in screen after authenticating properly.  I also ran 
>>> authconfig
>>> --mkhomedir update.  Thoughts?
>>>
>>> --
>>> Kristian Petersen
>>> System Administrator
>>> Dept. of Chemistry and Biochemistry
>>>
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>>> rahosted.org
>>>
>>>
>>
>>
>>
>>
>>
>
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Home directory not being created in log in

2018-01-29 Thread Jeff Goddard via FreeIPA-users 
Sounds like oddjobd isn't installed/configured.

On Mon, Jan 29, 2018 at 3:23 PM, Kristian Petersen via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> I am trying to set up a workstation running RHEL 7 with Gnome graphical
> environment.  I have enrolled this machine as a client in IPA using the
> --mkhomedir flag, however, the home directory is not being created when I
> log in.  Because the home directory doesn't get created at log in GDM kicks
> me back out to the log in screen after authenticating properly.  I also ran 
> authconfig
> --mkhomedir update.  Thoughts?
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Freeipa / IDM on a VM

2018-01-23 Thread Jeff Goddard via FreeIPA-users 
Not sure if this meets you definition of cluster or not but all of our IdM
servers are VMs. We have a multi-master set with standard replication. I
have IdM servers 2 in one location with 1 serving as DNS CA, LDAP, etc and
a second serving SMB shares and backing up the LDAP services. Across
private links in to another location/facility we have a second master with
the full suite of services installed and used. We do not use AD so the
level of complexity compared to mixed environments is low but everything
works fine for us.

Jeff

On Mon, Jan 22, 2018 at 9:49 PM, Grace Thompson via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Anybody running their freeipa / IDM cluster on a 100% virtualized
> environment?  We are running the full stack - DNS, ldap, Certs etc and I’m
> wondering if we can run it all on a VM environment. My concern is the
> chicken/egg scenario in case of a full DC recovery. Thoughts? Thanks.
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>



-- 
Jeff Goddard
Director of Information Technology
Emerlyn Technology
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org