[Freeipa-users] Re: How to recover from "split brain"

[Andrew Radygin via FreeIPA-users]

Though you can completely rebuild preprod servers, still it would be
interesting how to reconnect prod servers with replicas again.

2018-02-01 8:41 GMT+03:00 Rob Brown via FreeIPA-users <
freeipa-users@lists.fedorahosted.org>:

> ok, did a little googling, and seems like KRA refers to the "vault"
> feature?
> I didn't originally install this myself, so wasn't sure if it is used for
> anything critical.
> I ran:
> # ipa vault-find
> 
> 0 vaults matched
> 
> 
> Number of entries returned 0
> 
>
> So, can I assume it is safe to blow away and rebuild the server that has
> this role?
>
> On Wed, Jan 31, 2018 at 3:56 PM, Rob Brown 
> wrote:
>
>> I have 4 IPA servers, all masters, that were previously configured in a
>> "full mesh" replication.
>> 2 in "prod", 2 in "preprod".
>> While trying to fix a replication issue, I accidentally did a:
>> ipa-replica-manage del
>> on one of the prod servers for BOTH preprod servers.
>>
>> Now, the prod servers don't "see" either of the preprod servers, so I
>> effectively created a "split-brain" between the 2 environments. Preprod
>> still "knows about" the prod ipa servers, but I can't figure out how to
>> re-establish the replication agreements.
>>
>> I was about to just blow away the preprod servers and rebuild them (which
>> i did before on one of them) but noticed one of them has the "KRA" role,
>> and it is the only one in the domain that has it.
>> I don't know what that does, or what the effects would be if it went
>> away. I'm guessing bad.
>>
>> I have tried "ipa topologysegment-reinitialize domain" on the segments
>> that preprod still has, but those segments did not show up in prod.
>> ipa topologysuffix-verify domain says "in order" everywhere.
>>
>> At this point I am completely lost on how to proceed.
>>
>> What details can I provide for any help anyone is willing to provide?
>>
>>
>>
>>
>>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>


-- 
Best regards, Andrew.
___
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 recover from "split brain"

[Rob Brown via FreeIPA-users]

ok, did a little googling, and seems like KRA refers to the "vault" feature?
I didn't originally install this myself, so wasn't sure if it is used for
anything critical.
I ran:
# ipa vault-find

0 vaults matched


Number of entries returned 0


So, can I assume it is safe to blow away and rebuild the server that has
this role?

On Wed, Jan 31, 2018 at 3:56 PM, Rob Brown  wrote:

> I have 4 IPA servers, all masters, that were previously configured in a
> "full mesh" replication.
> 2 in "prod", 2 in "preprod".
> While trying to fix a replication issue, I accidentally did a:
> ipa-replica-manage del
> on one of the prod servers for BOTH preprod servers.
>
> Now, the prod servers don't "see" either of the preprod servers, so I
> effectively created a "split-brain" between the 2 environments. Preprod
> still "knows about" the prod ipa servers, but I can't figure out how to
> re-establish the replication agreements.
>
> I was about to just blow away the preprod servers and rebuild them (which
> i did before on one of them) but noticed one of them has the "KRA" role,
> and it is the only one in the domain that has it.
> I don't know what that does, or what the effects would be if it went away.
> I'm guessing bad.
>
> I have tried "ipa topologysegment-reinitialize domain" on the segments
> that preprod still has, but those segments did not show up in prod.
> ipa topologysuffix-verify domain says "in order" everywhere.
>
> At this point I am completely lost on how to proceed.
>
> What details can I provide for any help anyone is willing to provide?
>
>
>
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Issue with SCEP enrollment to sub-CA

[Trevor Vaughan via FreeIPA-users]

As an update, the sscep application set works properly with the sub-CA so
it's definitely an issue on the certmonger side of things.

sscep in AES mode throws an exception in Dogtag and, unfortunately, sscep
also doesn't support above SHA1.

That said, it's at least reasonable isolation of the issue at hand.

It looks like the sscep code may be able to be lifted directly into the
certmonger stack if the licenses are compatible without too much issue.

Thanks,

Trevor

On Wed, Jan 31, 2018 at 2:27 PM, Trevor Vaughan 
wrote:

> Hi Rob,
>
> Thanks for getting back to me, I have no idea how I missed this message.
>
> I dug through the CA and KRA debug logs and don't see any PKCS7 output
> anywhere.
>
> I've been running certmonger in debug mode connected to the foreground and
> haven't really gotten anywhere there either.
>
> I did determine that the spot where things are failing is at
> https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_1065 but I
> haven't been able to figure out how to print what is being received from
> the server.
>
> Running the 'scep-submit' command by hand with -C works as expected (of
> course Dogtag doesn't respond with server capabilities so it downgrades
> itself into instanity but that doesn't seem to be the issue). I also
> checked to see that the certmonger configuration is correct in the
> ~/.config/certmonger space and the entire certificate chain appears to be
> present as expected.
>
> Thanks,
>
> Trevor
>
> On Tue, Jan 30, 2018 at 10:38 AM, Rob Crittenden 
> wrote:
>
>> Trevor Vaughan via FreeIPA-users wrote:
>> > Hi All,
>> >
>> > I have a setup where I have a root CA and a sub CA and the sub CA is set
>> > up with a KRA and SCEP enabled.
>> >
>> > I've fired up certmonger and added the SCEP CA.
>> >
>> > When I attempt to request a certificate, the enrollment completes
>> > successfully per the Dogtag side of the equation but the response from
>> > the server cannot be decrypted by the client and I get the following
>> > error in the certmonger debug log:
>> >
>> > 2018-01-29 23:56:43 [5396] Child output:
>> > "Error: failed to verify signature on server
>> > response.
>> > "
>> > 2018-01-29 23:56:43 [5396] Error: failed to verify signature on server
>> > response.
>> >
>> > The following commands were used for server addition and certificate
>> > registration.
>> >
>> > getcert add-scep-ca -c Site_CA -u
>> > https://ca.int.localdomain:8443/ca/cgi-bin/pkiclient.exe
>> >  -R
>> > /etc/pki/site-pki.pem
>> >
>> > getcert request -c Site_CA -k /etc/pki/my_cert.pem -f
>> > /etc/pki/my_cert.pub -I Host_Cert -R -w -L password
>> >
>> > Looking at the certmonger code, it looks like it is completely skipping
>> > all of the case statements and simply dropping down to the 'goto:'
>> > https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_889
>> > 
>> >
>> > I've tried recompiling certmonger with some debug statements but I
>> > haven't managed to suss out what's going on. If someone could tell me
>> > how to print the actual response from the server, it would be
>> appreciated.
>> >
>> > It certainly feels like the SCEP support has taken a back seat to the
>> > CMC features but the CMC features just aren't ready to replace SCEP at
>> > this time and, of course, can't support a lot of hardware requirements.
>>
>> A couple of things to try:
>>
>> - look in the dogtag debug log (/var/log/pki-tomcat/somewhere). It may
>> have the raw PKCS#7 data to poke at
>> - stop the certmonger service and start it in a terminal with certmonger
>> -d 9 -n 2>&1 | tee /path/to/some/log and then redo the request. Again,
>> you may be able to get some data out of it.
>>
>> I haven't tried SCEP with a subCA. It could be there is some
>> disagreement about who is actually signing the response.
>>
>> rob
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699 x788 <(410)%20541-6699>
>
> -- This account not approved for unencrypted proprietary information --
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] How to recover from "split brain"

[Rob Brown via FreeIPA-users]

I have 4 IPA servers, all masters, that were previously configured in a
"full mesh" replication.
2 in "prod", 2 in "preprod".
While trying to fix a replication issue, I accidentally did a:
ipa-replica-manage del
on one of the prod servers for BOTH preprod servers.

Now, the prod servers don't "see" either of the preprod servers, so I
effectively created a "split-brain" between the 2 environments. Preprod
still "knows about" the prod ipa servers, but I can't figure out how to
re-establish the replication agreements.

I was about to just blow away the preprod servers and rebuild them (which i
did before on one of them) but noticed one of them has the "KRA" role, and
it is the only one in the domain that has it.
I don't know what that does, or what the effects would be if it went away.
I'm guessing bad.

I have tried "ipa topologysegment-reinitialize domain" on the segments that
preprod still has, but those segments did not show up in prod.
ipa topologysuffix-verify domain says "in order" everywhere.

At this point I am completely lost on how to proceed.

What details can I provide for any help anyone is willing to provide?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Announcing freeIPA 4.6.3

[Rob Crittenden via FreeIPA-users]

The FreeIPA team would like to announce FreeIPA 4.6.3 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds
for Fedora 27 will be available in the official COPR repository [1].

== Highlights in 4.6.3 ==

=== Bug fixes ===
FreeIPA 4.6.3 is a stabilization release for the features delivered as a
part of 4.6.0.
There are more than 31 bug-fixes details of which can be seen in
the list of resolved tickets below.

== Upgrading ==
Upgrade instructions are available on the Upgrade [2] page.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users
mailing list
(https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/)
or #freeipa channel on Freenode.


== Resolved tickets ==
* 7253 Custodia keys are not removed on uninstall
* 7381 Drop PyOpenSSL requirement
* 7373 "An internal error has occurred" show up when trying to add a
user to the Member User table in Vault.
* 7350 ObjectclassViolation seen while adding idview with
domain-resolution-order option.
* 7341 nsslapd-sasl-max-buffer-size is hardcoded to '2097152' during
install even if another value was provided in an LDIF (
--dirsrv-config-file )
* 7338 FreeIPA server install/upgrade does not process schema.d/ files
correctly
* 7333 Need to document kinit_lifetime in /etc/ipa/default.conf
* 7318 Cannot uninstall ipaserver after fresh install - {'desc': "Can't
contact LDAP server", 'errno': 111, 'info': 'Connection refused'}
* 7315 Packaging: use pylint 1.7.5 and remove disable for import stat
* 7312 Turn installutils.set_directive() into a context manager
* 7288 set_directive can overwrite wrong directives
* 7280 CA less IPA install with external certificates fails on RHEL 7 in
FIPS mode
* 7276 ipatest: automation for pagure ticket 7174
* 7265 test_vault: increase WAIT_AFTER_ARCHIVE
* 7264 IPA trust-add internal error (expected security.dom_sid got None)
* 7250 Spelling error in ipa-replica-conncheck man page
* 7247 ipa-backup does not backup Custodia keys and files
* 7237 ipa-getkeytab man page should have more details about
consequences of krb5 key renewal
* 7231 ipa-restore broken with python2
* 7227 389-ds-base crashed as part of ipa-server-intall in ipa-uuid
* 7223 show REPLICA_FILE as optional when ipa-ca-install is executed
with --help
* 7221 Replica installation at domain-level 0 fails against upgraded
ipa-server
* 7220 Third KRA  installation in topology fails
* 7202 IPA User Details not being displayed in WebUI
* 7182 ca_less testcase fixes
* 7174 ipa-replica-install might fail because of an already existing
entry cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,$SUFFI
* 7169 domain resolution order field in Identity->ID Views->Settings tab
missing in WebUI
* 7168 IPA failing to authenticate via password+OTP on RHEL7.4 with fips
enabled
* 7161 ipaplatform module import error in 4.5 branch on f26 causing
server installation failure
* 7145 ca_certfile is not honored on API requests
* 7111 Incorrect attribute level rights (ipaallowedtoperform) of service
object
* 7016 ipa_server_certinstall - restart krb5kdc service after kdc cert
is installed
* 6968 Consider moving upgrades from rpm install post
* 6703 Enable ephemeral KRA requests
*  Unable to re-add broken AD trust - Unexpected Information received
* 6611 Second phase of --external-ca ipa-server-install setup fails when
dirsrv is not running
* 6371 host-find slowness caused by missing host attributes in index
* 6091 [CI test]: improve DNS locations test
* 5801 ipa-server-install: error: option --forwarder: invalid IP address
127.0.0.11: cannot use loopback IP address when using Docker embedded
DNS server
== Detailed changelog since 4.6.2 ==
=== Alexander Bokovoy (13) ===
* ipaserver/plugins/trust.py: pep8 compliance
* trust: detect and error out when non-AD trust with IPA domain name exists
* ipaserver/plugins/trust.py; fix some indenting issues
* ipa-extdom-extop: refactor nsswitch operations
* test_dns_plugin: cope with missing IPv6 in Travis
* travis-ci: collect logs from cmocka tests
* ipa-kdb: override krb5.conf when testing KDC code in cmocka
* adtrust: filter out subdomains when defining our topology to AD
* ipa-replica-manage: implicitly ignore initial time skew in force-sync
* ds: ignore time skew during initial replication step
* Make sure upgrade also checks for IPv6 stack
* OTP import: support hash names with HMAC- prefix
* dsinstance: Restore context after changing dse.ldif

=== Abhijeet Kasurde (3) ===
* Trivial typo fix.
* ipatests: Fix interactive prompt in ca_less tests
* tests: correct usage of hostname in logger in tasks

=== Alexander Koksharov (2) ===
* ensuring 389-ds plugins are enabled after install
* kra-install: better warning message

=== amitkuma (2) ===
* Custom ca-subject logging
* Documenting kinit_lifetime in /etc/ipa/default.conf

=== Aleksei Slaikovskii (9) ===
* test_backup_and_restore.py AssertionError fix
* ipalib/frontend.py output_for_cli loops optimization
* View plugin/command help

[Freeipa-users] Re: Host certificates association across IPA servers

[Rob Crittenden via FreeIPA-users]

David Harvey via FreeIPA-users wrote:
> Dear ipa-users,
> 
> I've recently observed a pattern where adding a host certificate to a
> host only shows the association in the GUI for the server which issues
> the cert. I'm running FreeIPA 4.4.4.
> 
> I request a certificate from the host(s) in question with something like:
> 
> ipa-getcert request -f /path -k /path -r
> 
> All IPA servers show the cert as being issued and valid on the
> certificates page.
> Visiting the "https://myserver/ipa/ui/#/e/host/details/hostame.fqdn
> shows a host certificate from the machine that issued the cert
> Visiting the same host page from other ipa servers does not show the
> host cert associated.
> Users and hosts continue to synchronise, as do other cert details!
> 
> I can manually associate the host to cert on other servers using the
> "add" button in the Host certifcate section of the host page, but this
> feels wrong.
> Any ideas on how to troubleshoot this? It feels like the CAs don't quite
> get which one is in charge, and could be a result of me tearing down the
> original ubuntu based ones to replace with fedora, or a mistake I have
> made whilst doing so.

I'd still check for replication issues.

Are you sure the host entries in LDAP are the same between the different
masters?

Can you look in /var/log/httpd/error_log to see if anything is being
logged when the certificate is not showing?

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: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

On 1/31/2018 4:07 PM, TomK via FreeIPA-users wrote:

On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote:

On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote:

On 1/31/2018 12:21 PM, TomK wrote:

On 1/31/2018 9:41 AM, Jakub Hrozek wrote:

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have 
two RHEL

7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02

Both connect to the same AD DC host below: addc-srv03.addom.com.
Verified krb5.conf and sssd.conf both are identical.  We can 
login on

the http-srv01 and can list all groups for an AD account.

On http-srv02 we cannot login and any group listing from the CLI 
result

only in the user's local groups.  No AD groups.

Logs give us the output below.  Short of adding in the entire log 
which
I might not be able to do till the end of the week, what could we 
look

at to resolve this?

There's very little available online on this error.  The RH solution
doesn't make sense since the first host connects and
authenticates users
just fine so it's definitely GC enabled.




--
Cheers,
Tom K.
- 




Living on earth is expensive, but it includes a free trip around
the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch]
(0x4000): dbus
conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] 
(0x4000):

Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
(0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] 
[sbus_get_sender_id_send]

(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]]
[dp_get_account_info_handler]
(0x0200): Got request for
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req]
(0x0400): DP
Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] 
(0x0400):

Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] 
[sdap_id_op_connect_step]

(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] 
[fo_resolve_service_send]

(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status]
(0x1000):
Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] 
(0x1000):
Port status of port 0 for server 'addc-srv03.addom.com' is 'not 
working'


What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?
It's debug_level = 9.  There was 1002 occurrances since I restarted 
sssd

last night.  If it's F/W, I'm not clear on the port this is referring
too.
Also confirmed that port 3268 from both clients to the AD DC is 
blocked in

F/W. However then that raises the question why authentication works on
http-srv01 even though traffic to port 3268 is also getting denied 
from that

host.


The 'port' here refers to an internal sssd structure that usually maps
to a network port, but not always.

Is there some more context around the very first 'not working' since the
sssd restart? Because here is not much, there's just connecting and then
not working which leaves me puzzled.

The very first state switch should have a message from
"_be_fo_set_port_status" which also includes who was the caller etc.
That should give some more context.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to 
freeipa-users-le...@lists.fedorahosted.org



Below is the snippet.

(Wed Jan 31 13:28:09 2018) [sssd[be[ADDOM]]] [ldb] (0x4000): Destroying 
timer event 0x5

[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote:

On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote:

On 1/31/2018 12:21 PM, TomK wrote:

On 1/31/2018 9:41 AM, Jakub Hrozek wrote:

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02

Both connect to the same AD DC host below: addc-srv03.addom.com.
Verified krb5.conf and sssd.conf both are identical.  We can login on
the http-srv01 and can list all groups for an AD account.

On http-srv02 we cannot login and any group listing from the CLI result
only in the user's local groups.  No AD groups.

Logs give us the output below.  Short of adding in the entire log which
I might not be able to do till the end of the week, what could we look
at to resolve this?

There's very little available online on this error.  The RH solution
doesn't make sense since the first host connects and
authenticates users
just fine so it's definitely GC enabled.




--
Cheers,
Tom K.
-


Living on earth is expensive, but it includes a free trip around
the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch]
(0x4000): dbus
conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
(0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]]
[dp_get_account_info_handler]
(0x0200): Got request for
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req]
(0x0400): DP
Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status]
(0x1000):
Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'


What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?

It's debug_level = 9.  There was 1002 occurrances since I restarted sssd
last night.  If it's F/W, I'm not clear on the port this is referring
too.

Also confirmed that port 3268 from both clients to the AD DC is blocked in
F/W. However then that raises the question why authentication works on
http-srv01 even though traffic to port 3268 is also getting denied from that
host.


The 'port' here refers to an internal sssd structure that usually maps
to a network port, but not always.

Is there some more context around the very first 'not working' since the
sssd restart? Because here is not much, there's just connecting and then
not working which leaves me puzzled.

The very first state switch should have a message from
"_be_fo_set_port_status" which also includes who was the caller etc.
That should give some more context.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


Below is the snippet.

(Wed Jan 31 13:28:09 2018) [sssd[be[ADDOM]]] [ldb] (0x4000): Destroying 
timer event 0x55d9c6aa2020 "ltdb_timeout"


(Wed Jan 31 13:28:09 2018) [sssd[be[ADDOM]]] [ldb] (0x

[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

On 1/31/2018 2:34 PM, Jakub Hrozek via FreeIPA-users wrote:

On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote:

On 1/31/2018 12:21 PM, TomK wrote:

On 1/31/2018 9:41 AM, Jakub Hrozek wrote:

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02

Both connect to the same AD DC host below: addc-srv03.addom.com.
Verified krb5.conf and sssd.conf both are identical.  We can login on
the http-srv01 and can list all groups for an AD account.

On http-srv02 we cannot login and any group listing from the CLI result
only in the user's local groups.  No AD groups.

Logs give us the output below.  Short of adding in the entire log which
I might not be able to do till the end of the week, what could we look
at to resolve this?

There's very little available online on this error.  The RH solution
doesn't make sense since the first host connects and
authenticates users
just fine so it's definitely GC enabled.




--
Cheers,
Tom K.
-


Living on earth is expensive, but it includes a free trip around
the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch]
(0x4000): dbus
conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
(0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]]
[dp_get_account_info_handler]
(0x0200): Got request for
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req]
(0x0400): DP
Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status]
(0x1000):
Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'


What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?

It's debug_level = 9.  There was 1002 occurrances since I restarted sssd
last night.  If it's F/W, I'm not clear on the port this is referring
too.

Also confirmed that port 3268 from both clients to the AD DC is blocked in
F/W. However then that raises the question why authentication works on
http-srv01 even though traffic to port 3268 is also getting denied from that
host.


The 'port' here refers to an internal sssd structure that usually maps
to a network port, but not always.

Is there some more context around the very first 'not working' since the
sssd restart? Because here is not much, there's just connecting and then
not working which leaves me puzzled.

The very first state switch should have a message from
"_be_fo_set_port_status" which also includes who was the caller etc.
That should give some more context.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


TY.  I've sent the snippet privately to you.

--
Cheers,
Tom K.
-

Living on earth is expensive, but it includ

[Freeipa-users] Re: Certificates renewing with the wrong Subject

[Rob Crittenden via FreeIPA-users]

Roderick Johnstone via FreeIPA-users wrote:
> On 25/01/2018 16:56, Roderick Johnstone via FreeIPA-users wrote:
>> On 25/01/2018 13:43, Rob Crittenden via FreeIPA-users wrote:
>>> Roderick Johnstone via FreeIPA-users wrote:
 On 24/01/2018 21:09, Rob Crittenden via FreeIPA-users wrote:
> Roderick Johnstone via FreeIPA-users wrote:
>> On 24/01/2018 15:22, Rob Crittenden via FreeIPA-users wrote:
>>> Roderick Johnstone via FreeIPA-users wrote:
 On 23/01/2018 14:34, Rob Crittenden via FreeIPA-users wrote:
> Roderick Johnstone via FreeIPA-users wrote:
>> On 15/01/2018 20:07, Rob Crittenden via FreeIPA-users wrote:
>>> Roderick Johnstone via FreeIPA-users wrote:
 On 15/01/2018 16:06, Rob Crittenden via FreeIPA-users wrote:
> Roderick Johnstone via FreeIPA-users wrote:
>> Hi
>>
>> Our freeipa certificates need to be renewed due to passing
>> their
>> expiry
>> dates.
>>
>> While some certificates have renewed ok, the ipaCert and
>> auditSigningCert are renewing but the new certificates
>> have the
>> wrong
>> Subject.
>>
>> Environment is:
>> serverA (CRL, first, master) RHEL 7.3, ipa 4.4
>> serverB (replica) RHEL 7.3, ipa 4.4
>> serverC (replica) RHEL 7.4, ipa 4.5
>>
>> Once there are renewed certificates with the wrong Subject
>> present,
>> there are various problems with renewing the remaining
>> certificates,
>> which I think might be related to the bad Subject:
>>
>> 1) When just ipaCert has the wrong subject no further
>> renewals
>> happen
>>
>> 2) When auditSigningCert has the wrong subject the ipa
>> pki-tomcatd
>> service will not start and no further renewals happen.
>>
>> I've been round the following loop many times on ServerA, our
>> first
>> master:
>>
>> 1) Restore good certificates from backup
>> 2) Put the clock back to a time when certificates are all
>> valid
>> 3) Resubmit certificates for renewal
>>
>> Each time the ipaCert renews it has the same wrong
>> Subject. The
>> wrong
>> Subject includes the host name of one of our ipa client
>> systems.
>>
>> Each time the auditSigningCert renews it has the same wrong
>> Subject
>> but
>> a different subject to the ipaCert. The wrong Subject in this
>> case
>> includes the host name of a system which has never been an
>> ipa
>> client,
>> but might have been added and removed with ipa host-add
>> and ipa
>> host-del
>> for testing something, a while ago.
>>
>> As far as I can see, the "cert_subject" is set correctly
>> in the
>> file
>> /var/lib/certmonger/ until the point at which the
>> certificate is actually renewed.
>>
>> I'd be very grateful for some pointers as to which
>> configuration
>> options
>> and logs to check through to resolve this problem on our
>> production
>> system.
>>
>> If its of any relevance we did change which server is the
>> first
>> master
>> some time ago.
>
> I'd pull the CSR out of dogtag (CS.cfg) and/or certmonger
> to see
> what
> the subject is.

 I'm not seeing any obvious CSR fields in the
 /etc/pki/pki-tomcat/ca/CS.cfg file.
>>>
>>> foo.bar.certreq=
>>>
 The CSR in the certmonger requests file for the
 auditSigningCert
 seems
 to be showing with the correct Subject. This is different from
 the bad
 subject showing in the requests file field:
 cert_subject=
>>>
>>> The value of cert_subject comes from the issued certificate.
>>>
 and the Subject which is showing in the 'getcert list' output
 (which is
 the same as that in the cert_subject= field.>
 I'm not quite sure what this all means.
>>>
>>> It is displayed from the data within the tracked certmonger
>>> request.
>>>
>>> certmonger logs to syslog so you can check there or you can stop
>>> the
>>> process and run it manually with: certmonger -n -d 9 2>&1 | 

[Freeipa-users] Re: certmonger .service fail to start

[Rob Crittenden via FreeIPA-users]

barrykfl--- via FreeIPA-users wrote:
> Auto reboot fail , I just try manual bootup cermonger.service still fail
> 
> sudo systemctl -f start  certmonger.service
> 
> Jan 30 11:03:01 dbus[537]: [system] Activating systemd to h
> Jan 30 11:03:01 dbus-daemon[537]: dbus[537]: [system] Activ
> Jan 30 11:03:13  systemd-logind[2922]: Failed to enable subs
> Jan 30 11:03:13  systemd-logind[2922]: Failed to fully start
> Jan 30 11:03:13  dbus[537]: [system] Failed to activate serv
> Jan 30 11:03:13 systemd[1]: systemd-logind.service: main pr
> Jan 30 11:03:13 dbus-daemon[537]: dbus[537]: [system] Faile
> Jan 30 11:03:13 systemd[1]: Failed to start Login Service.
> 
> */usr/lib/polkit-1/polkitd
> 
> *
> *10:59:23.458: Loading rules from directory /etc/polkit-1/rules.d
> 10:59:23.458: Loading rules from directory /usr/share/polkit-1/rules.d
> 10:59:23.461: Finished loading, compiling and executing 7 rules
> Entering main event loop
> Connected to the system bus
> 10:59:23.463: Acquired the name org.freedesktop.PolicyKit1 on the system bus
> 11:00:28.891: Registered Authentication Agent for
> unix-process:2388:46107 (system bus name :1.55 [/usr/bin/pkttyagent
> --notify-fd 5 --fallback], object path
> /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
> 11:01:58.994: Unregistered Authentication Agent for
> unix-process:2388:46107 (system bus name :1.55, object path
> /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
> (disconnected from bus)*
> **
> *Any idea ...already no cluster just single server , every systemctl
> command fail and slow login.*
> *

I'm not sure what is going on with your messagebus. Are you seeing and
SELinux AVCs?

Can you describe how this machine is configured?

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: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[Jakub Hrozek via FreeIPA-users]

On Wed, Jan 31, 2018 at 01:18:27PM -0500, TomK via FreeIPA-users wrote:
> On 1/31/2018 12:21 PM, TomK wrote:
> > On 1/31/2018 9:41 AM, Jakub Hrozek wrote:
> > > See inline..
> > > 
> > > On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:
> > > > On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
> > > > My bad, did not include sssd-users earlier.  :(
> > > > 
> > > > > Hey All,
> > > > > 
> > > > > I'm wondering if anyone came across this error below.  We have two 
> > > > > RHEL
> > > > > 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02
> > > > > 
> > > > > Both connect to the same AD DC host below: addc-srv03.addom.com.
> > > > > Verified krb5.conf and sssd.conf both are identical.  We can login on
> > > > > the http-srv01 and can list all groups for an AD account.
> > > > > 
> > > > > On http-srv02 we cannot login and any group listing from the CLI 
> > > > > result
> > > > > only in the user's local groups.  No AD groups.
> > > > > 
> > > > > Logs give us the output below.  Short of adding in the entire log 
> > > > > which
> > > > > I might not be able to do till the end of the week, what could we look
> > > > > at to resolve this?
> > > > > 
> > > > > There's very little available online on this error.  The RH solution
> > > > > doesn't make sense since the first host connects and
> > > > > authenticates users
> > > > > just fine so it's definitely GC enabled.
> > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > Cheers,
> > > > Tom K.
> > > > -
> > > > 
> > > > 
> > > > Living on earth is expensive, but it includes a free trip around
> > > > the sun.
> > > > 
> > > > 
> > > > 
> > > > samba-libs-4.6.2-12.el7_4.x86_64
> > > > samba-client-libs-4.6.2-12.el7_4.x86_64
> > > > sssd-1.15.2-50.el7_4.6.x86_64
> > > > openldap-2.4.44-5.el7.x86_64
> > > > sssd-ldap-1.15.2-50.el7_4.6.x86_64
> > > > sssd-common-pac-1.15.2-50.el7_4.6.x86_64
> > > > samba-winbind-clients-4.6.2-12.el7_4.x86_64
> > > > samba-common-4.6.2-12.el7_4.noarch
> > > > sssd-client-1.15.2-50.el7_4.6.x86_64
> > > > sssd-proxy-1.15.2-50.el7_4.6.x86_64
> > > > samba-winbind-modules-4.6.2-12.el7_4.x86_64
> > > > python-sssdconfig-1.15.2-50.el7_4.6.noarch
> > > > sssd-ipa-1.15.2-50.el7_4.6.x86_64
> > > > samba-common-libs-4.6.2-12.el7_4.x86_64
> > > > sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
> > > > samba-winbind-4.6.2-12.el7_4.x86_64
> > > > sssd-krb5-1.15.2-50.el7_4.6.x86_64
> > > > sssd-ad-1.15.2-50.el7_4.6.x86_64
> > > > sssd-common-1.15.2-50.el7_4.6.x86_64
> > > > samba-common-tools-4.6.2-12.el7_4.x86_64
> > > > 
> > > > 
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch]
> > > > (0x4000): dbus
> > > > conn: 0x55b2e22e8700
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
> > > > Dispatching.
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
> > > > (0x2000): Received SBUS method
> > > > org.freedesktop.sssd.dataprovider.getAccountInfo on path
> > > > /org/freedesktop/sssd/dataprovider
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
> > > > (0x2000): Not a sysbus message, quit
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]]
> > > > [dp_get_account_info_handler]
> > > > (0x0200): Got request for
> > > > [0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req]
> > > > (0x0400): DP
> > > > Request [Account #4]: New request. Flags [0x0001].
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
> > > > Number of active DP request: 1
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
> > > > (0x1000): Domain ADDOM is Active
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
> > > > (0x1000): Domain ADDOM is Active
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
> > > > (0x4000): beginning to connect
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
> > > > (0x0100): Trying to resolve service 'AD_GC'
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status]
> > > > (0x1000):
> > > > Status of server 'addc-srv03.addom.com' is 'working'
> > > > (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
> > > > Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'
> > > 
> > > What debug level are you running with? Is this the first occurence of
> > > 'port not working' since sssd started?
> > It's debug_level = 9.  There was 1002 occurrances since I restarted sssd
> > last night.  If it's F/W, I'm not clear on the port this is referring
> > too.
> Also confirmed that port 3268 from both clients to the AD DC is blocked in
> F/W. However then that raises the question why authentication works on
> http-srv01 even though traffic to port 3268 is also getting denied from that
> host.

The 'port' here refers to an intern

[Freeipa-users] Re: Issue with SCEP enrollment to sub-CA

[Trevor Vaughan via FreeIPA-users]

Hi Rob,

Thanks for getting back to me, I have no idea how I missed this message.

I dug through the CA and KRA debug logs and don't see any PKCS7 output
anywhere.

I've been running certmonger in debug mode connected to the foreground and
haven't really gotten anywhere there either.

I did determine that the spot where things are failing is at
https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_1065 but I haven't
been able to figure out how to print what is being received from the server.

Running the 'scep-submit' command by hand with -C works as expected (of
course Dogtag doesn't respond with server capabilities so it downgrades
itself into instanity but that doesn't seem to be the issue). I also
checked to see that the certmonger configuration is correct in the
~/.config/certmonger space and the entire certificate chain appears to be
present as expected.

Thanks,

Trevor

On Tue, Jan 30, 2018 at 10:38 AM, Rob Crittenden 
wrote:

> Trevor Vaughan via FreeIPA-users wrote:
> > Hi All,
> >
> > I have a setup where I have a root CA and a sub CA and the sub CA is set
> > up with a KRA and SCEP enabled.
> >
> > I've fired up certmonger and added the SCEP CA.
> >
> > When I attempt to request a certificate, the enrollment completes
> > successfully per the Dogtag side of the equation but the response from
> > the server cannot be decrypted by the client and I get the following
> > error in the certmonger debug log:
> >
> > 2018-01-29 23:56:43 [5396] Child output:
> > "Error: failed to verify signature on server
> > response.
> > "
> > 2018-01-29 23:56:43 [5396] Error: failed to verify signature on server
> > response.
> >
> > The following commands were used for server addition and certificate
> > registration.
> >
> > getcert add-scep-ca -c Site_CA -u
> > https://ca.int.localdomain:8443/ca/cgi-bin/pkiclient.exe
> >  -R
> > /etc/pki/site-pki.pem
> >
> > getcert request -c Site_CA -k /etc/pki/my_cert.pem -f
> > /etc/pki/my_cert.pub -I Host_Cert -R -w -L password
> >
> > Looking at the certmonger code, it looks like it is completely skipping
> > all of the case statements and simply dropping down to the 'goto:'
> > https://pagure.io/certmonger/blob/master/f/src/pkcs7.c#_889
> > 
> >
> > I've tried recompiling certmonger with some debug statements but I
> > haven't managed to suss out what's going on. If someone could tell me
> > how to print the actual response from the server, it would be
> appreciated.
> >
> > It certainly feels like the SCEP support has taken a back seat to the
> > CMC features but the CMC features just aren't ready to replace SCEP at
> > this time and, of course, can't support a lot of hardware requirements.
>
> A couple of things to try:
>
> - look in the dogtag debug log (/var/log/pki-tomcat/somewhere). It may
> have the raw PKCS#7 data to poke at
> - stop the certmonger service and start it in a terminal with certmonger
> -d 9 -n 2>&1 | tee /path/to/some/log and then redo the request. Again,
> you may be able to get some data out of it.
>
> I haven't tried SCEP with a subCA. It could be there is some
> disagreement about who is actually signing the response.
>
> rob
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Documented monitoring best practices

[Alex Corcoles via FreeIPA-users]

Hi all,

Is there any official literature about how to monitor FreeIPA?

The upstream guide mentions:

1) Testing clients using id

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/client-test

2) Adding a user on a replica and verifying it appears on another server

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/replica-verify

There's also some troubleshooting appendices which look interesting.

I see also ipactl, "ipa ping", there seems to be:

https://www.freeipa.org/page/V4/Tool_to_Check_Status_of_All_Replicas
(but it seems dead)

https://www.freeipa.org/page/V4/Monitor_Replication_Topology

, and also some indepedent initiatives all over the web.

Is there any plan to provide an official way to monitor FreeIPA? My
foremost concern would be to ensure that all clients are correctly enrolled
and sudo/ssh work, so I am not locked out of my systems. Ensuring that
replication works seems good and popular. Of course I can check that all
services are running and ports respond.

What are the most common ways for FreeIPA to break?

Thoughts?

Álex

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/
___
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

[Petros Triantafyllidis via FreeIPA-users]

In case you are using kerberized NFS4, make sure that in your 
/etc/exports file on your NFS server security is set to sys. In my 
setup, that was the only option worked (for mkhomedir):


#cat /etc/exports
/export/home  192.168.161.0/24(rw,sec=sys:krb5p,no_root_squash)

Petros

On 01/31/2018 07:36 PM, Kristian Petersen wrote:

Yes it is being exported via NFS.

On Wed, Jan 31, 2018 at 9:51 AM, Petros Triantafyllidis > wrote:


Is your home directory exported as NFS? As far as I remember there
are some differences between CentOS 6 and 7 regarding NFS versions
that might affect you.

Petros



On 01/31/2018 06:30 PM, Kristian Petersen via FreeIPA-users wrote:

Update: I was putting together another client for a separate
purpose that runs RHEL 6 instead of RHEL 7 and everything
worked.  So there must be something different between RHEL6 and
RHEL7 that causes the steps I am using to fail on RHEL7.

On Mon, Jan 29, 2018 at 4:37 PM, Kristian Petersen
mailto:nesre...@chem.byu.edu>> wrote:

I think it is trying to write a lock file related to the X
session to my home directory, but it can't because the
location doesn't exist.  Interestingly enough, I tried
creating the directory manually and I get "permission denied"
even if running as root.  Could this be a problem related to
IPA trying to automount home directories?

On Mon, Jan 29, 2018 at 2:56 PM, Jeff Goddard
mailto:jgodd...@emerlyn.com>> wrote:

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
mailto:nesre...@chem.byu.edu>> 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
mailto:jgodd...@emerlyn.com>>
wrote:

Sounds like oddjobd isn't installed/configured.

On Mon, Jan 29, 2018 at 3:23 PM, Kristian
Petersen via FreeIPA-users
mailto: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










-- 
Kristian Petersen

System Administrator
Dept. of Chemistry and Biochemistry









-- 
Kristian Petersen

System Administrator
Dept. of Chemistry and Biochemistry




-- 
Kristian Petersen

System Administrator
Dept. of Chemistry and Biochemistry


___
FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org

To unsubscribe send an email tofreeipa-users-le...@lists.fedorah

[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

On 1/31/2018 12:21 PM, TomK wrote:

On 1/31/2018 9:41 AM, Jakub Hrozek wrote:

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02

Both connect to the same AD DC host below: addc-srv03.addom.com.
Verified krb5.conf and sssd.conf both are identical.  We can login on
the http-srv01 and can list all groups for an AD account.

On http-srv02 we cannot login and any group listing from the CLI result
only in the user's local groups.  No AD groups.

Logs give us the output below.  Short of adding in the entire log which
I might not be able to do till the end of the week, what could we look
at to resolve this?

There's very little available online on this error.  The RH solution
doesn't make sense since the first host connects and authenticates 
users

just fine so it's definitely GC enabled.




--
Cheers,
Tom K.
- 



Living on earth is expensive, but it includes a free trip around the 
sun.




samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] 
(0x4000): dbus

conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
(0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] 
[dp_get_account_info_handler]
(0x0200): Got request for 
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] 
(0x0400): DP

Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] 
(0x1000):

Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'


What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?
It's debug_level = 9.  There was 1002 occurrances since I restarted sssd 
last night.  If it's F/W, I'm not clear on the port this is referring too.
Also confirmed that port 3268 from both clients to the AD DC is blocked 
in F/W. However then that raises the question why authentication works 
on http-srv01 even though traffic to port 3268 is also getting denied 
from that host.



(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080):
SSSD is unable to complete the full connection request, this internal 
status

does not necessarily indicate network port issues.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0020): No available servers for service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done]
(0x1000): Server resolution failed: [5]: Input/output error
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
(0x0400): Failed to connect to server, but ignore mark offline is 
enabled.

(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
(0x4000): notify error to op #1: 5 [Input/output error]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP
Request [Account #4]: Request handler finished [0]: Success
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP
Request [Account #4

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

[Kristian Petersen via FreeIPA-users]

Yes it is being exported via NFS.

On Wed, Jan 31, 2018 at 9:51 AM, Petros Triantafyllidis 
wrote:

> Is your home directory exported as NFS? As far as I remember there are
> some differences between CentOS 6 and 7 regarding NFS versions that might
> affect you.
>
> Petros
>
>
>
> On 01/31/2018 06:30 PM, Kristian Petersen via FreeIPA-users wrote:
>
> Update:  I was putting together another client for a separate purpose that
> runs RHEL 6 instead of RHEL 7 and everything worked.  So there must be
> something different between RHEL6 and RHEL7 that causes the steps I am
> using to fail on RHEL7.
>
> On Mon, Jan 29, 2018 at 4:37 PM, Kristian Petersen 
> wrote:
>
>> I think it is trying to write a lock file related to the X session to my
>> home directory, but it can't because the location doesn't exist.
>> Interestingly enough, I tried creating the directory manually and I get
>> "permission denied" even if running as root.  Could this be a problem
>> related to IPA trying to automount home directories?
>>
>> On Mon, Jan 29, 2018 at 2:56 PM, Jeff Goddard 
>> wrote:
>>
>>> 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 <
>>> nesre...@chem.byu.edu> 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

>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Kristian Petersen
>> System Administrator
>> Dept. of Chemistry and Biochemistry
>>
>
>
>
> --
> 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
>
>
>


-- 
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: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

On 1/31/2018 9:41 AM, Jakub Hrozek wrote:

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02

Both connect to the same AD DC host below: addc-srv03.addom.com.
Verified krb5.conf and sssd.conf both are identical.  We can login on
the http-srv01 and can list all groups for an AD account.

On http-srv02 we cannot login and any group listing from the CLI result
only in the user's local groups.  No AD groups.

Logs give us the output below.  Short of adding in the entire log which
I might not be able to do till the end of the week, what could we look
at to resolve this?

There's very little available online on this error.  The RH solution
doesn't make sense since the first host connects and authenticates users
just fine so it's definitely GC enabled.




--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus
conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
(0x2000): Received SBUS method
org.freedesktop.sssd.dataprovider.getAccountInfo on path
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP
Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000):
Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'


What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?
It's debug_level = 9.  There was 1002 occurrances since I restarted sssd 
last night.  If it's F/W, I'm not clear on the port this is referring too.



(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080):
SSSD is unable to complete the full connection request, this internal status
does not necessarily indicate network port issues.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
(0x0020): No available servers for service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done]
(0x1000): Server resolution failed: [5]: Input/output error
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
(0x0400): Failed to connect to server, but ignore mark offline is enabled.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
(0x4000): notify error to op #1: 5 [Input/output error]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP
Request [Account #4]: Request handler finished [0]: Success
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP
Request [Account #4]: Receiving request data.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success]
(0x0400): DP Request [Account #4]: Finished. Success.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] (0x1000): DP
Request [Account #4]: Returning [Internal Error]: 3,5,Gr

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

[Petros Triantafyllidis via FreeIPA-users]

Is your home directory exported as NFS? As far as I remember there are 
some differences between CentOS 6 and 7 regarding NFS versions that 
might affect you.


Petros


On 01/31/2018 06:30 PM, Kristian Petersen via FreeIPA-users wrote:
Update: I was putting together another client for a separate purpose 
that runs RHEL 6 instead of RHEL 7 and everything worked.  So there 
must be something different between RHEL6 and RHEL7 that causes the 
steps I am using to fail on RHEL7.


On Mon, Jan 29, 2018 at 4:37 PM, Kristian Petersen 
mailto:nesre...@chem.byu.edu>> wrote:


I think it is trying to write a lock file related to the X session
to my home directory, but it can't because the location doesn't
exist.  Interestingly enough, I tried creating the directory
manually and I get "permission denied" even if running as root. 
Could this be a problem related to IPA trying to automount home
directories?

On Mon, Jan 29, 2018 at 2:56 PM, Jeff Goddard
mailto:jgodd...@emerlyn.com>> wrote:

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
mailto:nesre...@chem.byu.edu>> 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
mailto:jgodd...@emerlyn.com>> wrote:

Sounds like oddjobd isn't installed/configured.

On Mon, Jan 29, 2018 at 3:23 PM, Kristian Petersen via
FreeIPA-users mailto: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










-- 
Kristian Petersen

System Administrator
Dept. of Chemistry and Biochemistry









-- 
Kristian Petersen

System Administrator
Dept. of Chemistry and Biochemistry




--
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: Home directory not being created in log in

[Kristian Petersen via FreeIPA-users]

Update:  I was putting together another client for a separate purpose that
runs RHEL 6 instead of RHEL 7 and everything worked.  So there must be
something different between RHEL6 and RHEL7 that causes the steps I am
using to fail on RHEL7.

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

> I think it is trying to write a lock file related to the X session to my
> home directory, but it can't because the location doesn't exist.
> Interestingly enough, I tried creating the directory manually and I get
> "permission denied" even if running as root.  Could this be a problem
> related to IPA trying to automount home directories?
>
> On Mon, Jan 29, 2018 at 2:56 PM, Jeff Goddard 
> wrote:
>
>> 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
>>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Kristian Petersen
> System Administrator
> Dept. of Chemistry and Biochemistry
>



-- 
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] Host certificates association across IPA servers

[David Harvey via FreeIPA-users]

Dear ipa-users,

I've recently observed a pattern where adding a host certificate to a host
only shows the association in the GUI for the server which issues the cert.
I'm running FreeIPA 4.4.4.

I request a certificate from the host(s) in question with something like:

ipa-getcert request -f /path -k /path -r

All IPA servers show the cert as being issued and valid on the certificates
page.
Visiting the "https://myserver/ipa/ui/#/e/host/details/hostame.fqdn shows a
host certificate from the machine that issued the cert
Visiting the same host page from other ipa servers does not show the host
cert associated.
Users and hosts continue to synchronise, as do other cert details!

I can manually associate the host to cert on other servers using the "add"
button in the Host certifcate section of the host page, but this feels
wrong.
Any ideas on how to troubleshoot this? It feels like the CAs don't quite
get which one is in charge, and could be a result of me tearing down the
original ubuntu based ones to replace with fedora, or a mistake I have made
whilst doing so.

Any advice appreciated,

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

[Freeipa-users] Re: [SSSD-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[Jakub Hrozek via FreeIPA-users]

See inline..

On Wed, Jan 31, 2018 at 03:23:57AM -0500, TomK wrote:
> On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
> My bad, did not include sssd-users earlier.  :(
> 
> > Hey All,
> > 
> > I'm wondering if anyone came across this error below.  We have two RHEL
> > 7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02
> > 
> > Both connect to the same AD DC host below: addc-srv03.addom.com.
> > Verified krb5.conf and sssd.conf both are identical.  We can login on
> > the http-srv01 and can list all groups for an AD account.
> > 
> > On http-srv02 we cannot login and any group listing from the CLI result
> > only in the user's local groups.  No AD groups.
> > 
> > Logs give us the output below.  Short of adding in the entire log which
> > I might not be able to do till the end of the week, what could we look
> > at to resolve this?
> > 
> > There's very little available online on this error.  The RH solution
> > doesn't make sense since the first host connects and authenticates users
> > just fine so it's definitely GC enabled.
> > 
> 
> 
> -- 
> Cheers,
> Tom K.
> -
> 
> Living on earth is expensive, but it includes a free trip around the sun.
> 
> 
> 
> samba-libs-4.6.2-12.el7_4.x86_64
> samba-client-libs-4.6.2-12.el7_4.x86_64
> sssd-1.15.2-50.el7_4.6.x86_64
> openldap-2.4.44-5.el7.x86_64
> sssd-ldap-1.15.2-50.el7_4.6.x86_64
> sssd-common-pac-1.15.2-50.el7_4.6.x86_64
> samba-winbind-clients-4.6.2-12.el7_4.x86_64
> samba-common-4.6.2-12.el7_4.noarch
> sssd-client-1.15.2-50.el7_4.6.x86_64
> sssd-proxy-1.15.2-50.el7_4.6.x86_64
> samba-winbind-modules-4.6.2-12.el7_4.x86_64
> python-sssdconfig-1.15.2-50.el7_4.6.noarch
> sssd-ipa-1.15.2-50.el7_4.6.x86_64
> samba-common-libs-4.6.2-12.el7_4.x86_64
> sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
> samba-winbind-4.6.2-12.el7_4.x86_64
> sssd-krb5-1.15.2-50.el7_4.6.x86_64
> sssd-ad-1.15.2-50.el7_4.6.x86_64
> sssd-common-1.15.2-50.el7_4.6.x86_64
> samba-common-tools-4.6.2-12.el7_4.x86_64
> 
> 
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): dbus
> conn: 0x55b2e22e8700
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler]
> (0x2000): Received SBUS method
> org.freedesktop.sssd.dataprovider.getAccountInfo on path
> /org/freedesktop/sssd/dataprovider
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send]
> (0x2000): Not a sysbus message, quit
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_get_account_info_handler]
> (0x0200): Got request for [0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): DP
> Request [Account #4]: New request. Flags [0x0001].
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400):
> Number of active DP request: 1
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
> (0x1000): Domain ADDOM is Active
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state]
> (0x1000): Domain ADDOM is Active
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step]
> (0x4000): beginning to connect
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
> (0x0100): Trying to resolve service 'AD_GC'
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] (0x1000):
> Status of server 'addc-srv03.addom.com' is 'working'
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000):
> Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'

What debug level are you running with? Is this the first occurence of
'port not working' since sssd started?

> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080):
> SSSD is unable to complete the full connection request, this internal status
> does not necessarily indicate network port issues.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send]
> (0x0020): No available servers for service 'AD_GC'
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done]
> (0x1000): Server resolution failed: [5]: Input/output error
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
> (0x0400): Failed to connect to server, but ignore mark offline is enabled.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done]
> (0x4000): notify error to op #1: 5 [Input/output error]
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP
> Request [Account #4]: Request handler finished [0]: Success
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP
> Request [Account #4]: Receiving request data.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success]
> (0x0400): DP Request [Account #4]: Finished. Success.
> (Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] (0x1000): DP
> Request 

[Freeipa-users] Re: Howto renew certificates with external CA?

[Harald.Husemann--- via FreeIPA-users]

Hello Flo,

I've checked the certificates, there are several ones in the LDAP databases 
(got them with "ldapsearch -x -D "cn=Directory Manager" -W -b 
"uid=pkiuser,ou=people,o=ipaca", hope that's correct?) and one of them is 
identical to the one which I've got with certutil.
I've also checked AVC, but as far as I see there are no issues, avcstat gives 
"ERROR: open '(null)/avc/cache_stats': No such file or directory". That’s what 
I would expect, since SELinux is disabled in /etc/selinux/config.

Many thanks for your support and your quick responses, 

kind regards from Germany,

Harald
-- 
Dipl.-Ing. (FH)
Harald Husemann

Senior System Administrator
Managed Services

Phone: +49 231 9505-222
Mobile: +49 1570 11 22 22 2
harald.husem...@materna.de

www.materna.de | Newsletter | Twitter | XING | Facebook | google+

Materna GmbH | Voßkuhle 37 | D-44141 Dortmund | Germany
Geschäftsführer: Helmut Binder, Michael Knopp
Amtsgericht Dortmund HRB 5839


-Ursprüngliche Nachricht-
Von: Florence Blanc-Renaud [mailto:f...@redhat.com] 
Gesendet: Mittwoch, 31. Januar 2018 09:36
An: FreeIPA users list 
Cc: Husemann, Harald 
Betreff: Re: [Freeipa-users] Re: Howto renew certificates with external CA?

On 01/30/2018 05:17 PM, Harald Husemann via FreeIPA-users wrote:
> Hello Flo,
> 
> and thanks again for your response. First of all, I've figured out that 
> the package "pki-symkey" was missing, so I've installed it with yum. 
> Now, according to systemctl, pki-tomcatd is running:
> 
> root@mat-ipa-master-1:~$ systemctl status pki-tomcatd@pki-tomcat.service
> ● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
>     Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; 
> vendor preset: disabled)
>     Active: active (running) since Wed 2018-01-10 10:08:25 CET; 3min 55s 
> ago
> (...)
> 
> But, ipactl still complains that it is stopped:
> 
> root@mat-ipa-master-1:~$ ipactl start --ignore-service-failures
> Existing service file detected!
> Assuming stale, cleaning and proceeding
> Starting Directory Service
> (...)
> Failed to start pki-tomcatd Service
> Forced start, ignoring pki-tomcatd Service, continuing normal operation
> (...)
> 
> As you suggested, I've checked the debug log 
> /var/log/pki/pki-tomcat/ca/debug:
> (...)
> Internal Database Error encountered: Could not connect to LDAP server 
> host mat-ipa-master-1.materna-com.de port 636 Error 
> netscape.ldap.LDAPException: Authentication failed (48)
> (...)
> 
> So, I've examined the config and the certificates, with the commands 
> from the blog post:
> 
> root@mat-ipa-master-1:~$ grep internaldb.ldapauth 
> /etc/pki/pki-tomcat/ca/CS.cfg
> internaldb.ldapauth.authtype=SslClientAuth
> internaldb.ldapauth.bindDN=cn=Directory Manager
> internaldb.ldapauth.bindPWPrompt=internaldb
> internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
> root@mat-ipa-master-1:~$ grep internaldb.ldapconn 
> /etc/pki/pki-tomcat/ca/CS.cfg
> internaldb.ldapconn.host=mat-ipa-master-1.materna-com.de
> internaldb.ldapconn.port=636
> internaldb.ldapconn.secureConn=true
> 
> Ok, we're using LDAPS.
> 
> root@mat-ipa-master-1:~$ certutil -L -d /etc/pki/pki-tomcat/alias -n 
> 'subsystemCert cert-pki-ca'
> Certificate:
>      Data:
>      Version: 3 (0x2)
>      Serial Number: 33 (0x21)
>      Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
>      Issuer: "CN=Certificate Authority,O=MATERNA-COM.DE"
>      Validity:
>      Not Before: Fri Jan 12 23:56:02 2018
>      Not After : Sat Jan 13 14:45:00 2018
> (...)
> 
> Interesting, I've reset the date to Jan 10th:
> 
> root@mat-ipa-master-1:~$ date
> Wed Jan 10 10:05:49 CET 2018
> 
> So, the certificate is not expired, but invalid since it's too new?!
> Never mind, going further:
> 
> root@mat-ipa-master-1:~$ grep internal 
> /var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > /tmp/pwdfile.txt
> root@mat-ipa-master-1:~$ certutil -K -d /etc/pki/pki-tomcat/alias -f 
> /tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca'
> certutil: Checking token "NSS Certificate DB" in slot "NSS User Private 
> Key and Certificate Services"
> certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized 
> Object Identifier.
> 
> Do you have an idea why the key for this OID cannot be found?
> 

Hi,

let's not focus on this issue and try to check what went wrong. Can you 
compare the content of the certificate field in 
uid=pkidbuser,ou=people,o=ipaca and the blob that can be seen with:
certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a

This one is often the culprit, linked to SElinux issues. By the way, did 
you check if there were any AVC?

Flo
> Thanks, and best regards from Germany,
> 
> Harald
> 
> 
> 
> On 30.01.2018 14:05, Florence Blanc-Renaud wrote:
>> On 01/24/2018 07:35 PM, Harald.Husemann--- via FreeIPA-users wrote:
>>> Hello Flo,
>>>
>>> thanks for your answer, and for the explanation of the certutil 
>>> output. I have tried your sugg

[Freeipa-users] Re: Howto renew certificates with external CA?

[Florence Blanc-Renaud via FreeIPA-users]

On 01/30/2018 05:17 PM, Harald Husemann via FreeIPA-users wrote:

Hello Flo,

and thanks again for your response. First of all, I've figured out that 
the package "pki-symkey" was missing, so I've installed it with yum. 
Now, according to systemctl, pki-tomcatd is running:


root@mat-ipa-master-1:~$ systemctl status pki-tomcatd@pki-tomcat.service
● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
    Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; 
vendor preset: disabled)
    Active: active (running) since Wed 2018-01-10 10:08:25 CET; 3min 55s 
ago

(...)

But, ipactl still complains that it is stopped:

root@mat-ipa-master-1:~$ ipactl start --ignore-service-failures
Existing service file detected!
Assuming stale, cleaning and proceeding
Starting Directory Service
(...)
Failed to start pki-tomcatd Service
Forced start, ignoring pki-tomcatd Service, continuing normal operation
(...)

As you suggested, I've checked the debug log 
/var/log/pki/pki-tomcat/ca/debug:

(...)
Internal Database Error encountered: Could not connect to LDAP server 
host mat-ipa-master-1.materna-com.de port 636 Error 
netscape.ldap.LDAPException: Authentication failed (48)

(...)

So, I've examined the config and the certificates, with the commands 
from the blog post:


root@mat-ipa-master-1:~$ grep internaldb.ldapauth 
/etc/pki/pki-tomcat/ca/CS.cfg

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert cert-pki-ca
root@mat-ipa-master-1:~$ grep internaldb.ldapconn 
/etc/pki/pki-tomcat/ca/CS.cfg

internaldb.ldapconn.host=mat-ipa-master-1.materna-com.de
internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn=true

Ok, we're using LDAPS.

root@mat-ipa-master-1:~$ certutil -L -d /etc/pki/pki-tomcat/alias -n 
'subsystemCert cert-pki-ca'

Certificate:
     Data:
     Version: 3 (0x2)
     Serial Number: 33 (0x21)
     Signature Algorithm: PKCS #1 SHA-256 With RSA Encryption
     Issuer: "CN=Certificate Authority,O=MATERNA-COM.DE"
     Validity:
     Not Before: Fri Jan 12 23:56:02 2018
     Not After : Sat Jan 13 14:45:00 2018
(...)

Interesting, I've reset the date to Jan 10th:

root@mat-ipa-master-1:~$ date
Wed Jan 10 10:05:49 CET 2018

So, the certificate is not expired, but invalid since it's too new?!
Never mind, going further:

root@mat-ipa-master-1:~$ grep internal 
/var/lib/pki/pki-tomcat/conf/password.conf | cut -d= -f2 > /tmp/pwdfile.txt
root@mat-ipa-master-1:~$ certutil -K -d /etc/pki/pki-tomcat/alias -f 
/tmp/pwdfile.txt -n 'subsystemCert cert-pki-ca'
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private 
Key and Certificate Services"
certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized 
Object Identifier.


Do you have an idea why the key for this OID cannot be found?



Hi,

let's not focus on this issue and try to check what went wrong. Can you 
compare the content of the certificate field in 
uid=pkidbuser,ou=people,o=ipaca and the blob that can be seen with:

certutil -L -d /etc/pki/pki-tomcat/alias -n 'subsystemCert cert-pki-ca' -a

This one is often the culprit, linked to SElinux issues. By the way, did 
you check if there were any AVC?


Flo

Thanks, and best regards from Germany,

Harald



On 30.01.2018 14:05, Florence Blanc-Renaud wrote:

On 01/24/2018 07:35 PM, Harald.Husemann--- via FreeIPA-users wrote:

Hello Flo,

thanks for your answer, and for the explanation of the certutil 
output. I have tried your suggestion, first with sudo:


hhuseman@mat-ipa-master-1:~$ sudo kinit -kt /etc/krb5.keytab
[sudo] password for hhuseman:
Sorry, try again.
[sudo] password for hhuseman:
Sorry, try again.
[sudo] password for hhuseman:
sudo: 2 incorrect password attempts

I'm quite sure my password is correct, so it seems there's something 
broken here also, since sudo worked before the certificate update. My 
next try was running the command as root:


hhuseman@mat-ipa-master-1:~$ su -
Password:
root@mat-ipa-master-1:~$ kinit -kt /etc/krb5.keytab
root@mat-ipa-master-1:~$ exit
logout

As you see, there is no output at all, so I tried it again with -V:

root@mat-ipa-master-1:~$ kinit -V -kt /etc/krb5.keytab
Using existing cache: persistent:0:krb_ccache_VPUg94b
Using principal: host/mat-ipa-master-1.materna-com...@materna-com.de
Using keytab: /etc/krb5.keytab
Authenticated to Kerberos v5
root@mat-ipa-master-1:~$

I have also re-checked the certificate which is issued by the 
HTTPS-Server in my browser, it is still the old one.

And, I've tried to get the list of certificates with ipa-getcert:

root@mat-ipa-master-1:~$ ipa-getcert list
Number of certificates and requests being tracked: 5.
Request ID '20170303080146':
 status: CA_UNREACHABLE
 ca-error: Server at 
https://mat-ipa-master-1.materna-com.de/ipa/xml failed request, will 
retry: -504 (libcurl failed to execute the HTTP

[Freeipa-users] Re: Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

On 1/31/2018 3:18 AM, TomK via FreeIPA-users wrote:
My bad, did not include sssd-users earlier.  :(


Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL 
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02


Both connect to the same AD DC host below: addc-srv03.addom.com. 
Verified krb5.conf and sssd.conf both are identical.  We can login on 
the http-srv01 and can list all groups for an AD account.


On http-srv02 we cannot login and any group listing from the CLI result 
only in the user's local groups.  No AD groups.


Logs give us the output below.  Short of adding in the entire log which 
I might not be able to do till the end of the week, what could we look 
at to resolve this?


There's very little available online on this error.  The RH solution 
doesn't make sense since the first host connects and authenticates users 
just fine so it's definitely GC enabled.





--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): 
dbus conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): 
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] 
(0x2000): Received SBUS method 
org.freedesktop.sssd.dataprovider.getAccountInfo on path 
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] 
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] 
[dp_get_account_info_handler] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): 
DP Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): 
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] 
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] 
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] 
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] 
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] 
(0x1000): Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): 
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080): 
SSSD is unable to complete the full connection request, this internal 
status does not necessarily indicate network port issues.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] 
(0x0020): No available servers for service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done] 
(0x1000): Server resolution failed: [5]: Input/output error
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] 
(0x0400): Failed to connect to server, but ignore mark offline is enabled.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] 
(0x4000): notify error to op #1: 5 [Input/output error]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP 
Request [Account #4]: Request handler finished [0]: Success
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP 
Request [Account #4]: Receiving request data.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success] 
(0x0400): DP Request [Account #4]: Finished. Success.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] 
(0x1000): DP Request [Account #4]: Returning [Internal Error]: 3,5,Group 
lookup failed
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_table_value_destructor] 
(0x0400): Removing [0:1:0x0001:2::ADDOM:name=unix-admin-group@addom] 
from reply

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

[Freeipa-users] Getting DP Request [Account #4]: Returning [Internal Error]: 3,5,Group lookup failed

[TomK via FreeIPA-users]

Hey All,

I'm wondering if anyone came across this error below.  We have two RHEL 
7.4 servers with SSSD 1.15.2: http-srv01 and http-srv02


Both connect to the same AD DC host below: addc-srv03.addom.com. 
Verified krb5.conf and sssd.conf both are identical.  We can login on 
the http-srv01 and can list all groups for an AD account.


On http-srv02 we cannot login and any group listing from the CLI result 
only in the user's local groups.  No AD groups.


Logs give us the output below.  Short of adding in the entire log which 
I might not be able to do till the end of the week, what could we look 
at to resolve this?


There's very little available online on this error.  The RH solution 
doesn't make sense since the first host connects and authenticates users 
just fine so it's definitely GC enabled.


--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.



samba-libs-4.6.2-12.el7_4.x86_64
samba-client-libs-4.6.2-12.el7_4.x86_64
sssd-1.15.2-50.el7_4.6.x86_64
openldap-2.4.44-5.el7.x86_64
sssd-ldap-1.15.2-50.el7_4.6.x86_64
sssd-common-pac-1.15.2-50.el7_4.6.x86_64
samba-winbind-clients-4.6.2-12.el7_4.x86_64
samba-common-4.6.2-12.el7_4.noarch
sssd-client-1.15.2-50.el7_4.6.x86_64
sssd-proxy-1.15.2-50.el7_4.6.x86_64
samba-winbind-modules-4.6.2-12.el7_4.x86_64
python-sssdconfig-1.15.2-50.el7_4.6.noarch
sssd-ipa-1.15.2-50.el7_4.6.x86_64
samba-common-libs-4.6.2-12.el7_4.x86_64
sssd-krb5-common-1.15.2-50.el7_4.6.x86_64
samba-winbind-4.6.2-12.el7_4.x86_64
sssd-krb5-1.15.2-50.el7_4.6.x86_64
sssd-ad-1.15.2-50.el7_4.6.x86_64
sssd-common-1.15.2-50.el7_4.6.x86_64
samba-common-tools-4.6.2-12.el7_4.x86_64


(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): 
dbus conn: 0x55b2e22e8700
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_dispatch] (0x4000): 
Dispatching.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_message_handler] 
(0x2000): Received SBUS method 
org.freedesktop.sssd.dataprovider.getAccountInfo on path 
/org/freedesktop/sssd/dataprovider
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sbus_get_sender_id_send] 
(0x2000): Not a sysbus message, quit
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] 
[dp_get_account_info_handler] (0x0200): Got request for 
[0x2][BE_REQ_GROUP][name=unix-admin-group@addom]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): 
DP Request [Account #4]: New request. Flags [0x0001].
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_attach_req] (0x0400): 
Number of active DP request: 1
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] 
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sss_domain_get_state] 
(0x1000): Domain ADDOM is Active
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_step] 
(0x4000): beginning to connect
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] 
(0x0100): Trying to resolve service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_server_status] 
(0x1000): Status of server 'addc-srv03.addom.com' is 'working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x1000): 
Port status of port 0 for server 'addc-srv03.addom.com' is 'not working'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [get_port_status] (0x0080): 
SSSD is unable to complete the full connection request, this internal 
status does not necessarily indicate network port issues.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [fo_resolve_service_send] 
(0x0020): No available servers for service 'AD_GC'
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [be_resolve_server_done] 
(0x1000): Server resolution failed: [5]: Input/output error
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] 
(0x0400): Failed to connect to server, but ignore mark offline is enabled.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [sdap_id_op_connect_done] 
(0x4000): notify error to op #1: 5 [Input/output error]
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_done] (0x0400): DP 
Request [Account #4]: Request handler finished [0]: Success
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [_dp_req_recv] (0x0400): DP 
Request [Account #4]: Receiving request data.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_list_success] 
(0x0400): DP Request [Account #4]: Finished. Success.
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_req_reply_std] 
(0x1000): DP Request [Account #4]: Returning [Internal Error]: 3,5,Group 
lookup failed
(Tue Jan 30 19:00:01 2018) [sssd[be[ADDOM]]] [dp_table_value_destructor] 
(0x0400): Removing [0:1:0x0001:2::ADDOM:name=unix-admin-group@addom] 
from reply

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