[Freeipa-users] Re: IPA CA allow CSR SAN names in external domains

2017-10-20 Thread Fraser Tweedale via FreeIPA-users 
On Fri, Oct 20, 2017 at 10:59:36AM -0700, Steve Dainard via FreeIPA-users wrote:
> Hello
> 
> I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be
> able to add SAN's for a different dns domain than exists in the IPA realm.
> The dns for 'otherdomain.com' is handled by active directory which my IPA
> server has a cross-forest trust with.
> 
> ie:
> host: client1.ipadomain.com
> certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com,
> servicename.otherdomain.com
> 
> When I try to submit this CSR with 'ipa-getcert request' the IPA server
> denies with: "The service principal for subject alt name
> servicename.otherdomain.com in certificate request does not exist"
> 
> It seems that the default CAACL enforces a profile named
> 'caIPAserviceCert', but I'm having some trouble determining what can be
> modified (or cloned and changed in a new profile) that would allow  the CA
> to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the
> SAN.
> 
> This is the only section in the profile that contains SAN:
> policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
> policyset.serverCertSet.12.constraint.name=No Constraint
> policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
> policyset.serverCertSet.12.default.name=Copy Common Name to Subject
> Alternative Name
> 
> Thanks,
> Steve
>
You can add a principal alias to the service principal:

  % ipa service-add-principal HTTP/client1.ipadomain.com \
  HTTP/servicename.otherdomain.com

Then the CSR validation routine will see the
`servicename.otherdomain.com' SAN dnsName as a valid SAN for the
subject principal.

(This feature was added in FreeIPA 4.5)

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

[Freeipa-users] IPA CA allow CSR SAN names in external domains

2017-10-20 Thread Steve Dainard via FreeIPA-users 
Hello

I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be
able to add SAN's for a different dns domain than exists in the IPA realm.
The dns for 'otherdomain.com' is handled by active directory which my IPA
server has a cross-forest trust with.

ie:
host: client1.ipadomain.com
certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com,
servicename.otherdomain.com

When I try to submit this CSR with 'ipa-getcert request' the IPA server
denies with: "The service principal for subject alt name
servicename.otherdomain.com in certificate request does not exist"

It seems that the default CAACL enforces a profile named
'caIPAserviceCert', but I'm having some trouble determining what can be
modified (or cloned and changed in a new profile) that would allow  the CA
to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the
SAN.

This is the only section in the profile that contains SAN:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
policyset.serverCertSet.12.default.name=Copy Common Name to Subject
Alternative Name

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

[Freeipa-users] Re: ipa-cacert-manage vs NIS support

2017-10-20 Thread Alexander Bokovoy via FreeIPA-users 

On pe, 20 loka 2017, Harald Dunkel via FreeIPA-users wrote:

Hi folks,

I had to replace the CA chain about 3 months ago, using
ipa-cacert-manage. Question:

Does this affect freeipa's NIS support? Is there a hidden
certificate somewhere I missed to renew?

NIS does not utilize SSL as far as I know.


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

[Freeipa-users] ipa-cacert-manage vs NIS support

2017-10-20 Thread Harald Dunkel via FreeIPA-users 
Hi folks,

I had to replace the CA chain about 3 months ago, using
ipa-cacert-manage. Question:

Does this affect freeipa's NIS support? Is there a hidden
certificate somewhere I missed to renew?

The freeipa servers are running Centos 7.3 and 7.4. 


Every helpful comment is highly appreciated
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: mailing list archive out of date

2017-10-20 Thread Harald Dunkel via FreeIPA-users 
On Fri, 20 Oct 2017 12:30:50 +0200
Rob Crittenden via FreeIPA-users  wrote:

> 
> the list moved earlier this year to 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/
> 

Thanx very much for your pointer. Apparently the old mailing 
list archive is still much more attractive to Google.

I liked the spartanic design, too.


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

[Freeipa-users] Announcing SSSD 1.16.0

2017-10-20 Thread Jakub Hrozek via FreeIPA-users 
SSSD 1.16.0
===

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

The tarball can be downloaded from https://releases.pagure.org/SSSD/sssd/

RPM packages will be made available for Fedora shortly.

Feedback

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

Highlights
--

Security fixes
^^
 * This release fixes CVE-2017-12173: Unsanitized input when searching in
   local cache database. SSSD stores its cached data in an LDAP like local
   database file using libldb. To lookup cached data LDAP search filters
   like (objectClass=user)(name=user_name) are used. However, in
   sysdb_search_user_by_upn_res(), the input was not sanitized and
   allowed to manipulate the search filter for cache lookups. This would
   allow a logged in user to discover the password hash of a different user.

New Features

 * SSSD now supports session recording configuration through tlog. This
   feature enables recording of everything specific users see or type
   during their sessions on a text terminal. For more information, see
   the sssd-session-recording(5) manual page.

 * SSSD can act as a client agent to deliver
   Fleet Commander 
   policies defined on an IPA server. Fleet Commander provides a
   configuration management interface that is controlled centrally and
   that covers desktop, applications and network configuration.

 * Several new systemtap  probes
   were added into various locations in SSSD code to assist in
   troubleshooting and analyzing performance related issues. Please see the
   sssd-systemtap(5) manual page for more information.

 * A new LDAP provide access control mechanism that allows to restrict
   access based on PAM's rhost data field was added. For more details,
   please consult the sssd-ldap(5) manual page, in particular the 
   options ldap_user_authorized_rhost and the rhost value of
   ldap_access_filter.

Performance enhancements

 * Several attributes in the SSSD cache that are quite often used during
   cache searches were not indexed. This release adds the missing indices,
   which improves SSSD performance in large environments.

Notable bug fixes
^
 * The SSSD libwbclient implementation adjusted its behaviour in order to
   be compatible with Winbind's return value of wbcAuthenticateUserEx().
   This enables the SSSD libwbclient library to work with Samba-4.6 or newer.

 * SSSD's plugin for MIT Kerberos to send the PAC to the PAC responder
   did not protect the communication with the PAC responder with a mutex.
   This was causing multi-threaded applications that process the Kerberos
   PAC to miss a reply from SSSD and then were blocked until the default
   client timeout of 300 seconds passed. This release adds the mutex,
   which fixes the PAC responder usage in multi-threaded environments.

 * Previously, SSSD used to refresh several expired sudo rules by combining
   them into a long LDAP filter. This was ineffective, because the LDAP server
   had to process the query, but at that point, the client was quite often
   querying most or all of the sudo rules anyway. In this version, when
   the number of sudo rules to be refreshed exceeds the value of a new option
   sudo_threshold, all sudo rules are fetched instead.

 * A bug in the sudo integration that prevented the rules from matching if the
   user name referenced in that rule was overriden with sss_override or
   IPA ID views was fixed

 * When SSSD is configured with id_provider=ad, then a Kerberos
   configuration is created that instructs libkrb5 to use TCP for communication
   with the AD DC by default.  This would save switching from UDP to TCP, which
   happens almost every time with the ad provider due to the PAC attached to
   the Kerberos ticket.

Packaging Changes
-
 * The sss_debuglevel and sss_cache utilities were superseded by
   sssctl commands sssctl debug-level and sssctl cache-expire,
   respectively. While this change is backwards-compatible in the sense
   that the old commands continue to work, it is recommended to switch
   to the sssctl command which will in future encompass all SSSD
   administration tasks.

 * Two new manpages, sssd-session-recording(5) and sssd-systemtap(5)
   were added.

 * A new systemtap example script, which is packaged by default at
   /usr/share/sssd/systemtap/dp_request.stp was added.

 * A new directory called deskprofile under the SSSD state directory
   (typically /var/lib/sss/) was added. SSSD downloads the Fleet
   Commander profiles into this directory.

Documentation Changes
-
 * The ldap_user_certificate option has changed its

[Freeipa-users] Re: Unable to sign CSR with multiple CN in subject

2017-10-20 Thread Joel Kåberg via FreeIPA-users 
I'm trying to sign a CSR from an Cisco AnyConnect (server) instance to be used 
for site to site connections (client's are enrolled with the FreeIPA instance) 
- as far as I figured, validation only happens with the subject when using 
AnyConnect.

What I was hoping would happen is for the signing process is to simply 'copy' 
an sign what was inputted.

I will investigate certification profile's further and let you know how it goes.


Vennlig hilsen

Joel Kåberg
Sikkerhetsanalytiker, HelseCERT
Norsk Helsenett
+47 7356 5710 | +47 979 54 918
www.nhn.no

Denne e-post er kun bestemt for mottakeren nevnt over. Hvis du ved en feil 
skulle motta denne meldingen, må du ikke sende den videre eller kopiere den. 
Vennligst informer avsender og slett meldingen og eventuelle vedlegg fra din 
PC. Norsk Helsenett SF påtar seg ikke ansvar for endringer av innholdet etter 
at meldingen er sendt. Overføring av e-post er ikke garantert å være sikker, 
konfidensiell eller feilfri, fordi informasjon kan avbrytes, forvrenges, tapes, 
ødelegges, bli forsinket, være ufull­stendig eller inneholde skadelig kode. 
E-posten ble sjekket for skadelig kode før utsendelse fra Norsk Helsenett SF.

-Opprinnelig melding-
Fra: Fraser Tweedale [mailto:ftwee...@redhat.com]
Sendt: fredag 20. oktober 2017 01.25
Til: FreeIPA users list 
Kopi: Joel Kåberg 
Emne: Re: [Freeipa-users] Unable to sign CSR with multiple CN in subject

On Thu, Oct 19, 2017 at 10:40:12AM +, Joel Kåberg via FreeIPA-users wrote:
> Hello
>
> I'm trying to sign an CSR which has multiple CN in the certificate
> subject. When the certificate is signed it only contains one CN in the
> subject (should be 2, site1.domain.tld and site2.domain.tld), and
> furthermore only two alternative names (should be 3 – missing the
> site2.domain.tld), see below for output example.
>
> Does anyone why this is happening, and if there is a way around it?
> The documentation on this seems a bit sparse (or hard to find?), so
> I'd really appreciate some input.
>

This happens because the certificate profile does not take the Subject DN from 
the CSR verbatim; instead it picks a few bits out of the CSR.  This includes a 
single CN.  This is the behaviour of the SubjectNameDefault profile component; 
I do not know a workaround when using this component.

But you might be able to create a custom profile that uses the 
`UserSubjectNameDefault' component instead.  This one does copy the subject 
name from the CSR as-is.  I haven't tried this but if you try it out, let us 
know how it goes.

Cheers,
Fraser

> The private.domain.tld is an "virtual" host in Freeipa which has an
> service with 3 principal alias tied to it
> (SERVICE/private.domain@realm.secret.tld main@realm.secret.tld>,
> SERVICE/site1.domain@realm.secret.tld t...@realm.secret.tld>,
> SERVICE/site2.domain@realm.secret.tld t...@realm.secret.tld> )
> ---
> # openssl req -in signingrequest -noout -text Certificate Request:
> Data:
> Version: 0 (0x0)
> Subject: emailAddress=sec...@secret.tld, C=US, O=Secret Orginization, 
> CN=site1.secret.tld, CN=site2.secret.tld/unstructuredName=private.secret.tld
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Modulus:
> -censored-
> Exponent: 65537 (0x10001)
> Attributes:
> Requested Extensions:
> X509v3 Key Usage: critical
> Digital Signature, Key Encipherment
> X509v3 Subject Alternative Name:
> DNS:private.secret.tld
> Signature Algorithm: sha1WithRSAEncryption
> -censored-
>
> # ipa cert-request signingrequest.csr
> --principal=SERVICE/private.domain.tld
> --certificate-out=signingrequest.csr.signed
> Issuing CA: ipa
>   Certificate: -censored-
>   Subject: CN=site1.domain.tld,O=REALM.SECRET.TLD
>   Subject DNS name: private.domain.tld, site1.domain.tld
>   Issuer: CN=Certificate Authority,O=REALM.SECRET.TLD
>   Not Before: Thu Oct 19 10:27:13 2017 UTC
>   Not After: Sun Oct 20 10:27:13 2019 UTC
>   Serial number: 35
>   Serial number (hex): 0x23
>
> # openssl x509 -in signingrequest.csr.signed -noout -text
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 23 (0x17)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: O=REALM.SECRET.TLD, CN=Certificate Authority
> Validity
> Not Before: Thu Oct 19 10:27:13 2017 UTC
> Not After : Sun Oct 20 10:27:13 2019 UTC
> Subject: O=REALM.SECRET.TLD, CN=site1.secret.tld
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Modulus:
>

[Freeipa-users] Re: mailing list archive out of date

2017-10-20 Thread Rob Crittenden via FreeIPA-users 

Harald Dunkel via FreeIPA-users wrote:

Hi folks,

trying to solve some NIS problems I noticed that the archive
of this mailing list on https://www.redhat.com/archives/freeipa-users/
seems to be out of date.

Is this expected?


the list moved earlier this year to 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/


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: Unable to sign CSR with multiple CN in subject

2017-10-20 Thread Rob Crittenden via FreeIPA-users 

Fraser Tweedale via FreeIPA-users wrote:

On Thu, Oct 19, 2017 at 10:40:12AM +, Joel Kåberg via FreeIPA-users wrote:

Hello

I'm trying to sign an CSR which has multiple CN in the certificate
subject. When the certificate is signed it only contains one CN in
the subject (should be 2, site1.domain.tld and site2.domain.tld),
and furthermore only two alternative names (should be 3 – missing
the site2.domain.tld), see below for output example.

Does anyone why this is happening, and if there is a way around
it? The documentation on this seems a bit sparse (or hard to
find?), so I'd really appreciate some input.



This happens because the certificate profile does not take the
Subject DN from the CSR verbatim; instead it picks a few bits out of
the CSR.  This includes a single CN.  This is the behaviour of the
SubjectNameDefault profile component; I do not know a workaround
when using this component.

But you might be able to create a custom profile that uses the
`UserSubjectNameDefault' component instead.  This one does copy the
subject name from the CSR as-is.  I haven't tried this but if you
try it out, let us know how it goes.

Cheers,
Fraser


I just wonder if he is trying to do SAN via the subject which AFAIU 
won't work. I believe only the RDN will be used when using subject to 
compare to hostname (and even that is being rapidly deprecated and not 
supported).


rob




The private.domain.tld is an "virtual" host in Freeipa which has an service with 3 principal 
alias tied to it 
(SERVICE/private.domain@realm.secret.tld, 
SERVICE/site1.domain@realm.secret.tld, 
SERVICE/site2.domain@realm.secret.tld )
---
# openssl req -in signingrequest -noout -text
Certificate Request:
Data:
Version: 0 (0x0)
Subject: emailAddress=sec...@secret.tld, C=US, O=Secret Orginization, 
CN=site1.secret.tld, CN=site2.secret.tld/unstructuredName=private.secret.tld
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
-censored-
Exponent: 65537 (0x10001)
Attributes:
Requested Extensions:
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Subject Alternative Name:
DNS:private.secret.tld
Signature Algorithm: sha1WithRSAEncryption
-censored-

# ipa cert-request signingrequest.csr --principal=SERVICE/private.domain.tld 
--certificate-out=signingrequest.csr.signed
Issuing CA: ipa
  Certificate: -censored-
  Subject: CN=site1.domain.tld,O=REALM.SECRET.TLD
  Subject DNS name: private.domain.tld, site1.domain.tld
  Issuer: CN=Certificate Authority,O=REALM.SECRET.TLD
  Not Before: Thu Oct 19 10:27:13 2017 UTC
  Not After: Sun Oct 20 10:27:13 2019 UTC
  Serial number: 35
  Serial number (hex): 0x23

# openssl x509 -in signingrequest.csr.signed -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 23 (0x17)
Signature Algorithm: sha256WithRSAEncryption
Issuer: O=REALM.SECRET.TLD, CN=Certificate Authority
Validity
Not Before: Thu Oct 19 10:27:13 2017 UTC
Not After : Sun Oct 20 10:27:13 2019 UTC
Subject: O=REALM.SECRET.TLD, CN=site1.secret.tld
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
-censored-
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:-censored-

Authority Information Access:
OCSP - URI:http://ipa-ca.secret.tld/ca/ocsp

X509v3 Key Usage: critical
Digital Signature, Non Repudiation, Key Encipherment, Data 
Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
X509v3 CRL Distribution Points:

Full Name:
  URI:http://ipa-ca.sensor.secret.tld/ipa/crl/MasterCRL.bin
CRL Issuer:
  DirName: O = ipaca, CN = Certificate Authority

X509v3 Subject Key Identifier:
-censored-
X509v3 Subject Alternative Name:
DNS:private.secret.tld, DNS:site1.secret.tld
Signature Algorithm: sha256WithRSAEncryption
 -censored-
---
Vennlig hilsen

Joel Kåberg
Sikkerhetsanalytiker, HelseCERT
norskhelsenett
 +47 7356 5710 |  +47 979 54 918
www.nhn.no


Denne e-post er kun bestemt for mottakeren nevnt over. Hvis du ved en feil 
skulle motta denne meldingen, må du ikke sende den videre

[Freeipa-users] Re: cross-forest trust, client system cannot id AD users.

2017-10-20 Thread Jakub Hrozek via FreeIPA-users 
On Thu, Oct 19, 2017 at 05:34:41PM -0700, Steve Dainard wrote:
> Thanks Jakub and Justin,
> 
> It definitely is related to the wheel group. For a quick explanation, the
> wheel group exists in AD with a gid of 10 so users who belong to that group
> automatically have wheel/sudo perms on EL systems (we use posix attributes
> in AD for all our users/groups).
> 
> The easy fix seems to have been to add a wheel group with gid 10 to the IPA
> side, no group members. Now I get:
>  uid=1587(steve.dain...@addomain.com) gid=1028(employ...@ipadomain.zone)
> groups=1028(employ...@ipadomain.zone),10(wheel),1027(clus...@addomain.com
> ),1029(sys...@addomain.com),1041(confluence-administrat...@addomain.com
> ),1060(employees-vancou...@addomain.com),1086(dev...@addomain.com)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> 
> I got the idea from the RH IPA docs mentioning if a user has a primary
> group in AD with a gid, the group must also exist in IPA albeit doesn't
> need any members. 
> If this step isn't completed some secondary group
> memberships may not be resolved on the IPA side.

Maybe the docs are not totally clear, but the requirement is a bit different
-- it is actually that each GID number the user is a member of (as reported
by "id -G") must be resolvable into a group object with getgrgid() (or,
with getent group $gidnumber) on the command line.

> 
> Its still a bit odd that the wheel group appears to be a client local wheel
> group rather than @IPADOMAIN. 

I think this is because /etc/nsswitch.conf defines "groups" as "files sss".

So the initgroups operation returns a list of gids, which are then translated
into names, but because files precedes sss, the local group name is used first.

By the way, you might be interested in
https://sourceware.org/glibc/wiki/Proposals/GroupMerging

(I keep forgetting it this is already backported to RHEL-7, though..)

> The 'employees@IPADOMAIN' group listed above
> is actually the primary gid in AD Unix attributes, and is defined in IPA
> with the same gid but has no members. I'm guess this is because an EL host
> /etc/group defines 'wheel' by default, but not 'employees'.
> 
> Once we get IPA into production I'll pull the wheel group out of AD and
> keep it defined in IPA only.
> 
> Thanks,
> Steve
> 
> On Thu, Oct 19, 2017 at 11:37 AM, Justin Stephenson via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> 
> > On 10/19/2017 02:14 PM, Jakub Hrozek via FreeIPA-users wrote:
> >
> >> On Tue, Oct 17, 2017 at 02:21:07PM -0700, Steve Dainard via FreeIPA-users
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> I've installed a 60 day 'self supported' trial of red hat idm on rhel7.
> >>> I've created a cross-forest trust with an AD domain (2012R2) which
> >>> already
> >>> has posix attributes in ldap for users and groups.
> >>>
> >>> On my ipa server I can id/getent my AD user, and can SSH to the ipa
> >>> server
> >>> with my AD credentials/kerberos ticket.
> >>> # id steve.dain...@addomain.com
> >>> uid=1587(steve.dain...@addomain.com) gid=1028(employees)
> >>> groups=1028(employees),1041(confluence-administrat...@addomain.com
> >>> ),1060(employees-vancou...@addomain.com),10(wheel),1027(clus
> >>> t...@addomain.com
> >>> ),1086(dev...@addomain.com),1029(sys...@addomain.com)
> >>>
> >>> I installed Centos 7.4 and joined it to the realm but I'm having
> >>> intermittent issues id'ing users. At first I couldn't id any AD user, but
> >>> then I added a trusted domain ldap_search_base to the ipa servers
> >>> sssd.conf:
> >>>
> >>> ldap_search_base = OU=Employees,OU=Users,OU=Accounts,DC=ADDOMAIN,DC=com
> >>>
> >>> This initially seemed to work intermittently, some users I could id and
> >>> some I could not. I also noticed that the group membership of the users I
> >>> could id was incomplete, notably I have an AD group 'wheel' with gid 10
> >>> that shows on the ipa server side when I id my AD user, but didn't show
> >>> on
> >>> the client side.
> >>>
> >>> I decided to clear out the cache files manually and restart sssd on the
> >>> client, and now I can't id my user, but I can id users outside of the
> >>> ldap_search_base, specifically user accounts which are inactive and exist
> >>> in a inactive-users OU ouside the ldap_search_base. Very confusing.
> >>>
> >>> The sssd server side seems to be iterating through all my AD users
> >>> account
> >>> names in the logs (debug_level = 10) and I don't feel comfortable posting
> >>> logs with their complete names online..
> >>>
> >>>
> >>> IPA server sssd.conf:
> >>>
> >>> [domain/IPADOMAIN.zone]
> >>> cache_credentials = True
> >>> krb5_store_password_if_offline = True
> >>> ipa_domain = IPADOMAIN.zone
> >>> id_provider = ipa
> >>> auth_provider = ipa
> >>> access_provider = ipa
> >>> ipa_hostname = ipa001.IPADOMAIN.zone
> >>> chpass_provider = ipa
> >>> ipa_server = ipa001.IPADOMAIN.zone
> >>> ipa_server_mode = True
> >>> ldap_tls_cacert = /etc/ipa/ca.crt
> >>> debug_level = 10
> >>>
> >>> [sssd]
>