[Freeipa-users] Re: Replica stopped working: pki-ca port failed?

[Lachlan Musicman via FreeIPA-users]

On 27 October 2017 at 07:38, Rob Crittenden  wrote:

> Lachlan Musicman via FreeIPA-users wrote:
>
> >
> > ipa -version
> > VERSION: 4.5.0, API_VERSION: 2.228
>
> It shouldn't be even trying port 7389 with v4.5.0. Very old versions of
> IPA used to use two separate 389-ds instances, one for the IPA data and
> one for the CA data. They were combined long ago. This could just be a
> check in case you had a very old master in which case this is a red
> herring.
>
>

I went back to take another look at the dirsrv logs after you said this,
and I saw something I didn't see yesterday. I notice that the cn has "meTo"
appended to the start of the master server name.

Is that meant to be that way, or have I mistyped in the wrong window at the
wrong time somewhere?

ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=
meTovmpr-linuxidm.unix.domain.com" (vmpr-linuxidm:389) - Replication bind
with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()


Cheers
L.


--
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "

*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Replica stopped working: pki-ca port failed?

[Lachlan Musicman via FreeIPA-users]

On 27 October 2017 at 10:32, Lachlan Musicman  wrote:

> On 27 October 2017 at 07:38, Rob Crittenden  wrote:
>
>> Lachlan Musicman via FreeIPA-users wrote:
>> >
>> > When I look at the ID Views in the interface, I get an "IPA Error 903:
>> > InternalError".
>>
>> See /var/log/httpd/error_log for details, there may be a python backtrace.
>>
>
> Sure do!
>
> [Thu Oct 26 12:57:25.413102 2017] [:error] [pid 1316] ipa: ERROR:
> non-public: RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty
> [Thu Oct 26 12:57:25.413118 2017] [:error] [pid 1316] Traceback (most
> recent call last):
> [Thu Oct 26 12:57:25.413121 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 367, in
> wsgi_execute
> [Thu Oct 26 12:57:25.413124 2017] [:error] [pid 1316] result =
> command(*args, **options)
> [Thu Oct 26 12:57:25.413126 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in
> __call__
> [Thu Oct 26 12:57:25.413128 2017] [:error] [pid 1316] return
> self.__do_call(*args, **options)
> [Thu Oct 26 12:57:25.413130 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in
> __do_call
> [Thu Oct 26 12:57:25.413133 2017] [:error] [pid 1316] ret =
> self.run(*args, **options)
> [Thu Oct 26 12:57:25.413135 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run
> [Thu Oct 26 12:57:25.413137 2017] [:error] [pid 1316] return
> self.execute(*args, **options)
> [Thu Oct 26 12:57:25.413139 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line
> 2050, in execute
> [Thu Oct 26 12:57:25.413141 2017] [:error] [pid 1316] truncated =
> callback(self, ldap, entries, truncated, *args, **options)
> [Thu Oct 26 12:57:25.413144 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 1123, in post_callback
> [Thu Oct 26 12:57:25.413146 2017] [:error] [pid 1316] ldap, entries,
> truncated, *args, **options)
> [Thu Oct 26 12:57:25.413148 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 829, in post_callback
> [Thu Oct 26 12:57:25.413151 2017] [:error] [pid 1316]
> self.obj.convert_anchor_to_human_readable_form(entry, **options)
> [Thu Oct 26 12:57:25.413153 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 733, in convert_anchor_to_human_readable_form
> [Thu Oct 26 12:57:25.413156 2017] [:error] [pid 1316] anchor
> [Thu Oct 26 12:57:25.413158 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line
> 632, in resolve_anchor_to_object_name
> [Thu Oct 26 12:57:25.413161 2017] [:error] [pid 1316] name =
> domain_validator.get_trusted_domain_object_from_sid(sid)
> [Thu Oct 26 12:57:25.413163 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 503, in
> get_trusted_domain_object_from_sid
> [Thu Oct 26 12:57:25.413165 2017] [:error] [pid 1316] attrs=attrs)
> [Thu Oct 26 12:57:25.413167 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 380, in
> get_trusted_domain_objects
> [Thu Oct 26 12:57:25.413170 2017] [:error] [pid 1316] entries =
> self.search_in_dc(domain, filter, attrs, scope, basedn)
> [Thu Oct 26 12:57:25.413172 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 689, in
> search_in_dc
> [Thu Oct 26 12:57:25.413174 2017] [:error] [pid 1316] info =
> self.__retrieve_trusted_domain_gc_list(domain)
> [Thu Oct 26 12:57:25.413176 2017] [:error] [pid 1316]   File
> "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 763, in
> __retrieve_trusted_domain_gc_list
> [Thu Oct 26 12:57:25.413179 2017] [:error] [pid 1316]
> os.path.join(paths.USR_SHARE_IPA_DIR, "smb.conf.empty"))
> [Thu Oct 26 12:57:25.413181 2017] [:error] [pid 1316] RuntimeError: Unable
> to load file /usr/share/ipa/smb.conf.empty
>
>
> >
>> > [26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could
>> > not get initial credentials for principal
>> > [ldap/vmdr-linuxidm.unix.domain@unix.domain.com
>> > ] in keytab
>> > [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
>> > requested realm)
>> >
>> > I can get `kinit admin` working fine. But there's something wrong. I
>> > don't know where to look exactly.
>>
>> KRB5_TRACE=/dev/stdout kinit admin
>>
>> See what KDC kinit is using. It should be using the local box because
>> masters should point only to themselves.
>>
>
> Yes, that command makes reference to it's own ip, eg: "Sending TCP request
> to stream 10.126.18.129:88"
>
>
>> > /var/log/httpd/error has this
>> >
>> > RuntimeError: Unable to load file /usr/sha

[Freeipa-users] Re: Replica stopped working: pki-ca port failed?

[Lachlan Musicman via FreeIPA-users]

On 27 October 2017 at 07:38, Rob Crittenden  wrote:

> Lachlan Musicman via FreeIPA-users wrote:
> >
> > When I look at the ID Views in the interface, I get an "IPA Error 903:
> > InternalError".
>
> See /var/log/httpd/error_log for details, there may be a python backtrace.
>

Sure do!

[Thu Oct 26 12:57:25.413102 2017] [:error] [pid 1316] ipa: ERROR:
non-public: RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty
[Thu Oct 26 12:57:25.413118 2017] [:error] [pid 1316] Traceback (most
recent call last):
[Thu Oct 26 12:57:25.413121 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 367, in
wsgi_execute
[Thu Oct 26 12:57:25.413124 2017] [:error] [pid 1316] result =
command(*args, **options)
[Thu Oct 26 12:57:25.413126 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 447, in __call__
[Thu Oct 26 12:57:25.413128 2017] [:error] [pid 1316] return
self.__do_call(*args, **options)
[Thu Oct 26 12:57:25.413130 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 475, in
__do_call
[Thu Oct 26 12:57:25.413133 2017] [:error] [pid 1316] ret =
self.run(*args, **options)
[Thu Oct 26 12:57:25.413135 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 797, in run
[Thu Oct 26 12:57:25.413137 2017] [:error] [pid 1316] return
self.execute(*args, **options)
[Thu Oct 26 12:57:25.413139 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/baseldap.py", line
2050, in execute
[Thu Oct 26 12:57:25.413141 2017] [:error] [pid 1316] truncated =
callback(self, ldap, entries, truncated, *args, **options)
[Thu Oct 26 12:57:25.413144 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line 1123,
in post_callback
[Thu Oct 26 12:57:25.413146 2017] [:error] [pid 1316] ldap, entries,
truncated, *args, **options)
[Thu Oct 26 12:57:25.413148 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line 829,
in post_callback
[Thu Oct 26 12:57:25.413151 2017] [:error] [pid 1316]
self.obj.convert_anchor_to_human_readable_form(entry, **options)
[Thu Oct 26 12:57:25.413153 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line 733,
in convert_anchor_to_human_readable_form
[Thu Oct 26 12:57:25.413156 2017] [:error] [pid 1316] anchor
[Thu Oct 26 12:57:25.413158 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/plugins/idviews.py", line 632,
in resolve_anchor_to_object_name
[Thu Oct 26 12:57:25.413161 2017] [:error] [pid 1316] name =
domain_validator.get_trusted_domain_object_from_sid(sid)
[Thu Oct 26 12:57:25.413163 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 503, in
get_trusted_domain_object_from_sid
[Thu Oct 26 12:57:25.413165 2017] [:error] [pid 1316] attrs=attrs)
[Thu Oct 26 12:57:25.413167 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 380, in
get_trusted_domain_objects
[Thu Oct 26 12:57:25.413170 2017] [:error] [pid 1316] entries =
self.search_in_dc(domain, filter, attrs, scope, basedn)
[Thu Oct 26 12:57:25.413172 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 689, in
search_in_dc
[Thu Oct 26 12:57:25.413174 2017] [:error] [pid 1316] info =
self.__retrieve_trusted_domain_gc_list(domain)
[Thu Oct 26 12:57:25.413176 2017] [:error] [pid 1316]   File
"/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 763, in
__retrieve_trusted_domain_gc_list
[Thu Oct 26 12:57:25.413179 2017] [:error] [pid 1316]
os.path.join(paths.USR_SHARE_IPA_DIR, "smb.conf.empty"))
[Thu Oct 26 12:57:25.413181 2017] [:error] [pid 1316] RuntimeError: Unable
to load file /usr/share/ipa/smb.conf.empty


>
> > [26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could
> > not get initial credentials for principal
> > [ldap/vmdr-linuxidm.unix.domain@unix.domain.com
> > ] in keytab
> > [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
> > requested realm)
> >
> > I can get `kinit admin` working fine. But there's something wrong. I
> > don't know where to look exactly.
>
> KRB5_TRACE=/dev/stdout kinit admin
>
> See what KDC kinit is using. It should be using the local box because
> masters should point only to themselves.
>

Yes, that command makes reference to it's own ip, eg: "Sending TCP request
to stream 10.126.18.129:88"


> > /var/log/httpd/error has this
> >
> > RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty
> >
> > Which is interesting. There's no file /usr/share/ipa/smb.conf.empty but
> > there is a /usr/share/ipa/smb.conf.template?
>
> Probably need more context.
>

I've only just realised this is the above error 

[Freeipa-users] Re: Swiching which FreeIPA server is the main CA

[Kristian Petersen via FreeIPA-users]

I checked the logs that turned up after running the find command suggested
by Jochen and only a couple of them turned up anything that mention pki or
pki-tomcat:

from /var/log/audit/audit.log:
type=SERVICE_START msg=audit(1508873851.623:163448): pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg='unit=pki-tomcatd@pki-tomcat comm="systemd"
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

from /var/log/messages:
Oct 26 16:01:58 ipa1 ns-slapd: [26/Oct/2017:16:01:58.077129423 -0600] - ERR
- slapi_ldap_bind - Error: could not bind id [cn=Replication Manager
cloneAgreement1-ipa2.chem.byu.edu-pki-tomcat,ou=csusers,cn=config]
authentication mechanism [SIMPLE]: error 32 (No such object)
Oct 26 16:01:58 ipa1 named-pkcs11[16463]: client 192.168.105.11#37937:
request has invalid signature: TSIG DHCP_UPDATER: tsig verify failure
(BADKEY)



On Thu, Oct 26, 2017 at 2:32 PM, Jochen Hein  wrote:

> Kristian Petersen via FreeIPA-users
>  writes:
>
> > The dirsrv log just shows a bunch of the following:
> > [13/Oct/2017:14:32:07.132312021 -0600] - ERR - slapi_ldap_bind - Error:
> > could not bind id [cn=Replication Manager cloneAgreement1-ipa
> > 2.chem.byu.edu-pki-tomcat,ou=csusers,cn=config] authentication mechanism
> > [SIMPLE]: error 32 (No such object)
> >
> > That makes sense though since pki-tomcat won't start.  Rob was asking
> what
> > was in the logs located at /var/log/pki/pki-tomcat/ca/debug, but that
> path
> > doesn't exist on any of my IPA servers.  He said that would normally be
> the
> > first place to look.  Hence, I am looking for other solutions.
>
> Brute force: reproduce the error and run "find /var/log -mmin -1 -type f
> -ls".
> This finds the files changed in the last minute - one of these might
> help.
>
> Jochen
>
> --
> This space is intentionally left blank.
>



-- 
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: Port 389

[Sean Hogan via FreeIPA-users]

Ok.. no worries.  Thanks Simo







From:   Simo Sorce via FreeIPA-users

To: FreeIPA users list 
Cc: Sean Hogan , Simo Sorce 
Date:   10/26/2017 02:17 PM
Subject:[Freeipa-users] Re: Port 389



On Thu, 2017-10-26 at 14:11 -0700, Sean Hogan via FreeIPA-users wrote:

> Hello IPA,

>

>   Hopefully a quick question.

>

> RHEL 7.3 IPA 4.4

>

>  I have been digging around RHEL docs

>
https://urldefense.proofpoint.com/v2/url?u=https-3A__access.redhat.com_solutions_357673&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=pAvZgCz4zBPNXNWPu8dLOYdmUIAP7pySuYQoq4H7yUs&m=M3GS01uKZUvxf9atkJNRslbDUFIirk4nvs1XLmsEE5E&s=ZF1CthjI5DDAlOhll_SNlHRwCqPzTHvQrRRt7dcKMeA&e=
 for firewall ports and it

> says

> 389 is required for replication of IPA servers and clients to IPA

> servers.

>

>   FreeIPA docs say this:

> SSL/startTLS  When possible, configure your LDAP client to

> communicate over

> SSL/TLS. You can either use port 389 and enable startTLS in the

> client or

> configure to use the ldaps port, 636. The IPA CA certificate can be

> found

> in /etc/ipa/ca.crt on all enrolled hosts.

>

>

>

>

>

>   Question is this... can IPA be configured without Port 389 at all

> for clients to comm with IPA servers?



Nope, sorry.

Most clients use SASL/GSSAPI to secure the connection, and that is done

over port 389.



>

>   I realize the starttls using 389 encrypts the comms but for our

> vlan firewall rules 389 is not something we really want to open.  It

> is easier to open IPA server IP to IPA server IP port 389 bi-

> direction if needed for replication but for clients it would be the

> whole subnet to IPA server 389.

> I also noticed somewhere that direct 636 instead of 389 with starttls

> for clients is deprecated but I think that was in Directory Server

> docs.







--

Simo Sorce

Sr. Principal Software Engineer

Red Hat, Inc

___
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: Port 389

[Simo Sorce via FreeIPA-users]

On Thu, 2017-10-26 at 14:11 -0700, Sean Hogan via FreeIPA-users wrote:
> Hello IPA,
> 
>   Hopefully a quick question.
> 
> RHEL 7.3 IPA 4.4
> 
>  I have been digging around RHEL docs
> https://access.redhat.com/solutions/357673 for firewall ports and it
> says
> 389 is required for replication of IPA servers and clients to IPA
> servers.
> 
>   FreeIPA docs say this:
> SSL/startTLS  When possible, configure your LDAP client to
> communicate over
> SSL/TLS. You can either use port 389 and enable startTLS in the
> client or
> configure to use the ldaps port, 636. The IPA CA certificate can be
> found
> in /etc/ipa/ca.crt on all enrolled hosts.
> 
> 
> 
> 
> 
>   Question is this... can IPA be configured without Port 389 at all
> for clients to comm with IPA servers?

Nope, sorry.
Most clients use SASL/GSSAPI to secure the connection, and that is done
over port 389.

> 
>   I realize the starttls using 389 encrypts the comms but for our
> vlan firewall rules 389 is not something we really want to open.  It
> is easier to open IPA server IP to IPA server IP port 389 bi-
> direction if needed for replication but for clients it would be the
> whole subnet to IPA server 389.
> I also noticed somewhere that direct 636 instead of 389 with starttls
> for clients is deprecated but I think that was in Directory Server
> docs.



-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Port 389

[Sean Hogan via FreeIPA-users]

Hello IPA,

  Hopefully a quick question.

RHEL 7.3 IPA 4.4

 I have been digging around RHEL docs
https://access.redhat.com/solutions/357673 for firewall ports and it says
389 is required for replication of IPA servers and clients to IPA servers.

  FreeIPA docs say this:
SSL/startTLS  When possible, configure your LDAP client to communicate over
SSL/TLS. You can either use port 389 and enable startTLS in the client or
configure to use the ldaps port, 636. The IPA CA certificate can be found
in /etc/ipa/ca.crt on all enrolled hosts.





  Question is this... can IPA be configured without Port 389 at all for
clients to comm with IPA servers?


  I realize the starttls using 389 encrypts the comms but for our vlan
firewall rules 389 is not something we really want to open.  It is easier
to open IPA server IP to IPA server IP port 389 bi-direction if needed for
replication but for clients it would be the whole subnet to IPA server 389.
I also noticed somewhere that direct 636 instead of 389 with starttls for
clients is deprecated but I think that was in Directory Server docs.





Sean Hogan


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

[Freeipa-users] Re: yum update caused FreeIPA to temporarily return NXDOMAIN for valid records

[Nicholas Hinds via FreeIPA-users]

On Thu, Oct 26, 2017 at 9:17 AM Rob Crittenden  wrote:

> Nicholas Hinds wrote:
> > I tried running `sudo service named-pkcs11 stop` before the yum update,
> > but FreeIPA still returned NXDOMAIN responses temporarily.
>
> You want the service named.
>
That service does not exist in my FreeIPA installation:
$ sudo service named status
Redirecting to /bin/systemctl status named.service
● named.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

Running `sudo service named stop` gives no output, and running `sudo ipactl
status` afterwards shows that "named" is still running:
$ sudo service named stop
Redirecting to /bin/systemctl stop named.service
$ sudo ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful


If I stop named-pkcs11, `sudo ipactl status` shows that "named" is stopped:
$ sudo service named-pkcs11 stop
Redirecting to /bin/systemctl stop named-pkcs11.service
$ sudo ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: STOPPED
httpd Service: RUNNING
ipa-custodia Service: RUNNING
ntpd Service: RUNNING
pki-tomcatd Service: RUNNING
smb Service: RUNNING
winbind Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful


So at least on my machine, stopping the OS service "named-pkcs11" stops
"named" for FreeIPA.


> > It seems like these responses occur about 10 seconds after the last log
> > entry in /var/log/ipaupgrade.log ("The ipa-server-upgrade command was
> > successful"). Based on the IPA "posttrans" script from the RPM, it seems
> > likely the NXDOMAIN responses are being returned while the
> > `/bin/systemctl restart ipa.service` command is running, however I
> > cannot reproduce the NXDOMAIN responses by running `/bin/systemctl
> > restart ipa.service` on its own. Something in the yum upgrade or
> > ipa-server-upgrade process seems to trigger this different behaviour.
>
> As I said, by default right now bind remains running while its backend,
> 389-ds, is unavailable during the package update process. The ipa
> service doesn't reproduce this because of the order in which the
> services are restarted.
>

If I stop the "ipa" service then start only bind ("named-pkcs11"), so the
backend isn't running, DNS queries return the "SERVFAIL" status rather than
"NXDOMAIN", which makes sense to me. They also do not return any authority
information. It does not appear that bind returns "NXDOMAIN" with incorrect
authority information if its backend is completely unavailable when it
starts.

If I start the "ipa" service and attempt to stop all of its components
apart from bind/named one by one (ipa-dnskeysyncd, winbind, smb, ntpd,
ipa-custodia, httpd, kadmin, krb5kdc, pki-tomcatd@pki-tomcat,
dirsrv@MY-DOMAIN), the DNS server continues to correctly respond to DNS
queries. This could be because I have a pair of replicated FreeIPA
instances, and once bind/named starts it knows how to query from the
secondary server? Although stopping FreeIPA on my second server does not
stop DNS queries from being answered - perhaps bind has just cached the
response for the test query I am using. Either way, stopping all of these
services including dirsrv (which I believe is the 389-ds backend process)
does not result in "NXDOMAIN" responses with incorrect authority
information.


> rob
>
> >
> > On Tue, Oct 24, 2017 at 1:45 PM Rob Crittenden  > > wrote:
> >
> > Nicholas Hinds via FreeIPA-users wrote:
> > > During an upgrade from 4.5.0-21.el7.centos.1.2
> > > to 4.5.0-21.el7.centos.2.2 on a CentOS 7.4 machine, FreeIPA's DNS
> > server
> > > briefly returned NXDOMAIN for records which existed in FreeIPA.
> These
> > > invalid responses were returned for a very short amount of time,
> but
> > > caused long-running issues with Java clients which tend to cache
> DNS
> > > responses. Upgraded packages included: 389-ds-base,
> 389-ds-base-libs,
> > > 389-ds-base-snmp, ipa-client, ipa-client-common, ipa-python-compat,
> > > ipa-server, ipa-server-common, ipa-server-dns, ipa-server-trust-ad,
> > > python2-ipa-server, and a dozen sss-related packages.
> > >
> > > I reproduced this in a FreeIPA test environment by running `while
> > true;
> > > do dig some.dns.entry.managed.by
> > .freeipa @ip.address.of.freeipa |
> > tee -a
> > > a-log-file; done` from one server, and running `yum update` on the
> > > FreeIPA machine. The invalid NXDOMAIN responses were returned some
> > time
> > > after the `yum update` logged 'Cleanup' for the RPMs, and seemed
> to be

[Freeipa-users] Re: yum update caused FreeIPA to temporarily return NXDOMAIN for valid records

[Nicholas Hinds via FreeIPA-users]

I tried running `sudo service named-pkcs11 stop` before the yum update, but
FreeIPA still returned NXDOMAIN responses temporarily.

It seems like these responses occur about 10 seconds after the last log
entry in /var/log/ipaupgrade.log ("The ipa-server-upgrade command was
successful"). Based on the IPA "posttrans" script from the RPM, it seems
likely the NXDOMAIN responses are being returned while the `/bin/systemctl
restart ipa.service` command is running, however I cannot reproduce the
NXDOMAIN responses by running `/bin/systemctl restart ipa.service` on its
own. Something in the yum upgrade or ipa-server-upgrade process seems to
trigger this different behaviour.

On Tue, Oct 24, 2017 at 1:45 PM Rob Crittenden  wrote:

> Nicholas Hinds via FreeIPA-users wrote:
> > During an upgrade from 4.5.0-21.el7.centos.1.2
> > to 4.5.0-21.el7.centos.2.2 on a CentOS 7.4 machine, FreeIPA's DNS server
> > briefly returned NXDOMAIN for records which existed in FreeIPA. These
> > invalid responses were returned for a very short amount of time, but
> > caused long-running issues with Java clients which tend to cache DNS
> > responses. Upgraded packages included: 389-ds-base, 389-ds-base-libs,
> > 389-ds-base-snmp, ipa-client, ipa-client-common, ipa-python-compat,
> > ipa-server, ipa-server-common, ipa-server-dns, ipa-server-trust-ad,
> > python2-ipa-server, and a dozen sss-related packages.
> >
> > I reproduced this in a FreeIPA test environment by running `while true;
> > do dig some.dns.entry.managed.by.freeipa @ip.address.of.freeipa | tee -a
> > a-log-file; done` from one server, and running `yum update` on the
> > FreeIPA machine. The invalid NXDOMAIN responses were returned some time
> > after the `yum update` logged 'Cleanup' for the RPMs, and seemed to be
> > during the 'Verifying' phase.
> >
> > These NXDOMAIN responses claimed that an upstream nameserver
> > (a.root-servers.net ) was the authority for
> > my zone:
> >
> > a-log-file-; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
> > some.dns.entry.managed.by.freeipa @172.16.0.77 
> > a-log-file-;; global options: +cmd
> > a-log-file-;; Got answer:
> > a-log-file:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2889
> > a-log-file-;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> > ADDITIONAL: 0
> > a-log-file-
> > a-log-file-;; QUESTION SECTION:
> > a-log-file-;some.dns.entry.managed.by.freeipa. IN A
> > a-log-file-
> > a-log-file-;; AUTHORITY SECTION:
> > a-log-file-.60INSOAa.root-servers.net .
> > nstld.verisign-grs.com . 2017102400 1800
> > 900 604800 86400
> > a-log-file-
> > a-log-file-;; Query time: 227 msec
> > a-log-file-;; SERVER: 172.16.0.77#53(172.16.0.77)
> > a-log-file-;; WHEN: Tue Oct 24 18:30:28 2017
> > a-log-file-;; MSG SIZE  rcvd: 130
> >
> > Usually when querying an invalid DNS entry, the dig output still claims
> > that my FreeIPA server is authoritative for the zone:
> > $ dig doesntexist.zone.managed.by.freeipa @172.16.0.77 <
> http://172.16.0.77>
> >
> > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
> > doesntexist.zone.managed.by.freeipa @172.16.0.77 
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59953
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;doesntexist.zone.managed.by.freeipa. IN A
> >
> > ;; AUTHORITY SECTION:
> > zone.managed.by.freeipa.30 INSOAidm01.freeipa.
> > hostmaster.zone.managed.by.freeipa. 1508869828 30 900 1209600 30
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 172.16.0.77#53(172.16.0.77)
> > ;; WHEN: Tue Oct 24 19:27:12 2017
> > ;; MSG SIZE  rcvd: 113
> >
> >
> > Is it possible that during a yum update, the FreeIPA DNS server
> > temporarily forgets what zones it's authoritative for (or forgets all
> > DNS records) and just delegates to the upstream DNS server for half a
> > second or so? Or is something else going on here?
> >
> > I'm open to suggestions.
>
> The LDAP server is brought down during upgrades which is likely the
> issue. bind can't connect to its backend. Why it returns NXDOMAIN I
> don't know.
>
> You may be able to manually work around this by manually stopping bind
> before updating IPA, then starting it again afterwards.
>
> 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: Replica stopped working: pki-ca port failed?

[Rob Crittenden via FreeIPA-users]

Lachlan Musicman via FreeIPA-users wrote:
> When I first installed our replica, it worked just fine - I could add a
> user and see it on the master server. And vice versa.
> 
> I recently went back to take a look and make sure everything was working
> - and it's not.
> 
> ipactl status shows everything is ok. Munge is up. I can ssh hostname
> between machines.
> 
> When I look at the ID Views in the interface, I get an "IPA Error 903:
> InternalError".

See /var/log/httpd/error_log for details, there may be a python backtrace.

> When I do an id  I get nosuch user.

https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html

> I did some googling. In /var log/dirsrv/domain/errors I found this:
> 
> [26/Oct/2017:12:31:23.454702287 +1100] - ERR - set_krb5_creds - Could
> not get initial credentials for principal
> [ldap/vmdr-linuxidm.unix.domain@unix.domain.com
> ] in keytab
> [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
> requested realm)
> 
> I can get `kinit admin` working fine. But there's something wrong. I
> don't know where to look exactly.

KRB5_TRACE=/dev/stdout kinit admin

See what KDC kinit is using. It should be using the local box because
masters should point only to themselves.

> /var/log/httpd/error has this
> 
> RuntimeError: Unable to load file /usr/share/ipa/smb.conf.empty
> 
> Which is interesting. There's no file /usr/share/ipa/smb.conf.empty but
> there is a /usr/share/ipa/smb.conf.template?

Probably need more context.

> 
> Ok, I think I've found the problem:
> 
> ipa-replica-conncheck -c -m 
> Failed to connect to port 7389 tcp on 10.126.18.73
>PKI-CA: Directory Service port (7389): FAILED
> ERROR: Port check failed! Inaccessible port(s): 7389 (TCP)
> 
> 
> On the master, pki-tomcatd is showing as OK, although nmap -sT -O
> localhost doesn't show 7389 open.
> 
> Where can I look next?
> 
> ipa -version
> VERSION: 4.5.0, API_VERSION: 2.228

It shouldn't be even trying port 7389 with v4.5.0. Very old versions of
IPA used to use two separate 389-ds instances, one for the IPA data and
one for the CA data. They were combined long ago. This could just be a
check in case you had a very old master in which case this is a red herring.

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: Swiching which FreeIPA server is the main CA

[Jochen Hein via FreeIPA-users]

Kristian Petersen via FreeIPA-users
 writes:

> The dirsrv log just shows a bunch of the following:
> [13/Oct/2017:14:32:07.132312021 -0600] - ERR - slapi_ldap_bind - Error:
> could not bind id [cn=Replication Manager cloneAgreement1-ipa
> 2.chem.byu.edu-pki-tomcat,ou=csusers,cn=config] authentication mechanism
> [SIMPLE]: error 32 (No such object)
>
> That makes sense though since pki-tomcat won't start.  Rob was asking what
> was in the logs located at /var/log/pki/pki-tomcat/ca/debug, but that path
> doesn't exist on any of my IPA servers.  He said that would normally be the
> first place to look.  Hence, I am looking for other solutions.

Brute force: reproduce the error and run "find /var/log -mmin -1 -type f -ls".
This finds the files changed in the last minute - one of these might
help.

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Swiching which FreeIPA server is the main CA

[Kristian Petersen via FreeIPA-users]

The dirsrv log just shows a bunch of the following:
[13/Oct/2017:14:32:07.132312021 -0600] - ERR - slapi_ldap_bind - Error:
could not bind id [cn=Replication Manager cloneAgreement1-ipa
2.chem.byu.edu-pki-tomcat,ou=csusers,cn=config] authentication mechanism
[SIMPLE]: error 32 (No such object)

That makes sense though since pki-tomcat won't start.  Rob was asking what
was in the logs located at /var/log/pki/pki-tomcat/ca/debug, but that path
doesn't exist on any of my IPA servers.  He said that would normally be the
first place to look.  Hence, I am looking for other solutions.

On Thu, Oct 26, 2017 at 12:37 PM, Jochen Hein  wrote:

> Kristian Petersen via FreeIPA-users
>  writes:
>
> > When I recently updated one of my IPA servers (it reports
> > 4.5.0-21.el7_4.1.2 in yum), the result was that it could not start back
> up
> > because pki-tomcatd kept failing.  I was able to get it running for now
> by
> > ignoring the failure of that one service, but I haven't been able to to
> > determine the cause.  The logs are pretty quiet on this one.  They show
> the
> > failure itself, but not information that helps me fix the problem.
>
> Can you show the relevant logs?  Is there something in the dirsrv logs
> at that time?  CA logs aren't easy to read, but should give at least a
> hint where to look further.
>
> Jochen
>
> --
> This space is intentionally left blank.
>



-- 
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: Swiching which FreeIPA server is the main CA

[Jochen Hein via FreeIPA-users]

Kristian Petersen via FreeIPA-users
 writes:

> When I recently updated one of my IPA servers (it reports
> 4.5.0-21.el7_4.1.2 in yum), the result was that it could not start back up
> because pki-tomcatd kept failing.  I was able to get it running for now by
> ignoring the failure of that one service, but I haven't been able to to
> determine the cause.  The logs are pretty quiet on this one.  They show the
> failure itself, but not information that helps me fix the problem.  

Can you show the relevant logs?  Is there something in the dirsrv logs
at that time?  CA logs aren't easy to read, but should give at least a
hint where to look further.

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Swiching which FreeIPA server is the main CA

[Kristian Petersen via FreeIPA-users]

When I recently updated one of my IPA servers (it reports
4.5.0-21.el7_4.1.2 in yum), the result was that it could not start back up
because pki-tomcatd kept failing.  I was able to get it running for now by
ignoring the failure of that one service, but I haven't been able to to
determine the cause.  The logs are pretty quiet on this one.  They show the
failure itself, but not information that helps me fix the problem.  It also
appears to be causing some weird UI issues.  Without the certificate stuff
working I can't add any new replicas as CAs because it can't send the
needed info to the new server.

I have talked a little bit with Rob Crittenden about this but always run
into an impasse hen trying to find the debug logs.

On Thu, Oct 26, 2017 at 10:25 AM, Florence Blanc-Renaud 
wrote:

> On 10/26/2017 04:58 PM, Kristian Petersen via FreeIPA-users wrote:
>
>> I am having problems with the server that currently is my main CA and was
>> considering trying to switch that function to a different server.  I have
>> tried some of the stuff I found online but the CA role can't be enabled on
>> another server because it is broken on the one that has it right now.
>> Hence the operation fails.  Any other ideas on how to resolve this?  It is
>> OK if I have to abandon my old certificates and generate entirely new one
>> on the new CA server.
>>
>> --
>> 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
>>
>> Hi,
>
> which issues do you currently have with the CA? Maybe we can help fix the
> CA first.
>
> Flo
>



-- 
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: Swiching which FreeIPA server is the main CA

[Florence Blanc-Renaud via FreeIPA-users]

On 10/26/2017 04:58 PM, Kristian Petersen via FreeIPA-users wrote:
I am having problems with the server that currently is my main CA and 
was considering trying to switch that function to a different server.  I 
have tried some of the stuff I found online but the CA role can't be 
enabled on another server because it is broken on the one that has it 
right now.  Hence the operation fails.  Any other ideas on how to 
resolve this?  It is OK if I have to abandon my old certificates and 
generate entirely new one on the new CA server.


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


Hi,

which issues do you currently have with the CA? Maybe we can help fix 
the CA first.


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

[Freeipa-users] Re: yum update caused FreeIPA to temporarily return NXDOMAIN for valid records

[Rob Crittenden via FreeIPA-users]

Nicholas Hinds wrote:
> I tried running `sudo service named-pkcs11 stop` before the yum update,
> but FreeIPA still returned NXDOMAIN responses temporarily.

You want the service named.

> It seems like these responses occur about 10 seconds after the last log
> entry in /var/log/ipaupgrade.log ("The ipa-server-upgrade command was
> successful"). Based on the IPA "posttrans" script from the RPM, it seems
> likely the NXDOMAIN responses are being returned while the
> `/bin/systemctl restart ipa.service` command is running, however I
> cannot reproduce the NXDOMAIN responses by running `/bin/systemctl
> restart ipa.service` on its own. Something in the yum upgrade or
> ipa-server-upgrade process seems to trigger this different behaviour.

As I said, by default right now bind remains running while its backend,
389-ds, is unavailable during the package update process. The ipa
service doesn't reproduce this because of the order in which the
services are restarted.

rob

> 
> On Tue, Oct 24, 2017 at 1:45 PM Rob Crittenden  > wrote:
> 
> Nicholas Hinds via FreeIPA-users wrote:
> > During an upgrade from 4.5.0-21.el7.centos.1.2
> > to 4.5.0-21.el7.centos.2.2 on a CentOS 7.4 machine, FreeIPA's DNS
> server
> > briefly returned NXDOMAIN for records which existed in FreeIPA. These
> > invalid responses were returned for a very short amount of time, but
> > caused long-running issues with Java clients which tend to cache DNS
> > responses. Upgraded packages included: 389-ds-base, 389-ds-base-libs,
> > 389-ds-base-snmp, ipa-client, ipa-client-common, ipa-python-compat,
> > ipa-server, ipa-server-common, ipa-server-dns, ipa-server-trust-ad,
> > python2-ipa-server, and a dozen sss-related packages.
> >
> > I reproduced this in a FreeIPA test environment by running `while
> true;
> > do dig some.dns.entry.managed.by
> .freeipa @ip.address.of.freeipa |
> tee -a
> > a-log-file; done` from one server, and running `yum update` on the
> > FreeIPA machine. The invalid NXDOMAIN responses were returned some
> time
> > after the `yum update` logged 'Cleanup' for the RPMs, and seemed to be
> > during the 'Verifying' phase.
> >
> > These NXDOMAIN responses claimed that an upstream nameserver
> > (a.root-servers.net 
> ) was the authority for
> > my zone:
> >
> > a-log-file-; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
> > some.dns.entry.managed.by
> .freeipa @172.16.0.77
>  
> > a-log-file-;; global options: +cmd
> > a-log-file-;; Got answer:
> > a-log-file:;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2889
> > a-log-file-;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> > ADDITIONAL: 0
> > a-log-file-
> > a-log-file-;; QUESTION SECTION:
> > a-log-file-;some.dns.entry.managed.by.freeipa. IN A
> > a-log-file-
> > a-log-file-;; AUTHORITY SECTION:
> > a-log-file-.60INSOAa.root-servers.net
>  .
> > nstld.verisign-grs.com 
> . 2017102400 1800
> > 900 604800 86400
> > a-log-file-
> > a-log-file-;; Query time: 227 msec
> > a-log-file-;; SERVER: 172.16.0.77#53(172.16.0.77)
> > a-log-file-;; WHEN: Tue Oct 24 18:30:28 2017
> > a-log-file-;; MSG SIZE  rcvd: 130
> >
> > Usually when querying an invalid DNS entry, the dig output still
> claims
> > that my FreeIPA server is authoritative for the zone:
> > $ dig doesntexist.zone.managed.by
> .freeipa @172.16.0.77
>  
> >
> > ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.7 <<>>
> > doesntexist.zone.managed.by
> .freeipa @172.16.0.77
>  
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59953
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;doesntexist.zone.managed.by
> .freeipa. IN A
> >
> > ;; AUTHORITY SECTION:
> > zone.managed.by.freeipa.30 INSOAidm01.freeipa.
> > hostmaster.zone.managed.by
> .freeipa. 1508869828 30 900
> 1209600 30
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 172.16.0.77#53(172.16.0.77)
> > ;; WHEN: Tue Oct 24 19:27:12 2017
> > ;; MSG SIZE  rcvd: 113
> >
> >
> > Is it possible that during a yum update, the FreeIPA DNS server
> > temporarily forgets what zones it's aut

[Freeipa-users] Re: Sync against AD group

[Rob Crittenden via FreeIPA-users]

Miguel Angel Coa M. wrote:
> Rob,
> My idea about A/D group is centralize the users for the winsync because
> some are in one OU and others in others (but i see this isn't possible)
> 
> eg.
> 
> Example2.com  <-- Domain root
> Builtin <-- Default 
> .
> .
> Users  <-- Default users  -> base search (CN=users,DC=example2, DC=com)
> .
> Area01  <-- Custom OU and i've some user for sync --> base search
> (OU=area01,DC=example2, DC=com)
> Area02 <-- Custom OU and i've others user for sync --> base search
> (OU=area02,DC=example2, DC=com)
> Area03 <-- Custom OU and i've others user for sync --> base
> search (OU=area03,DC=example2, DC=com)
> ..
> AreaXX <-- Custom OU and i've others user for sync  --> base
> search (OU=areaXX,DC=example2, DC=com)
> 
> 
> ¿In my case what could I do?

Right, moving all the users to a custom OU or otherwise separate subtree
would be the only way to do it AFAIK.

rob

> 
> 
> Thanks.
> 
> 
> Saludos.
> ---
> Miguel Coa M.
> 
> 2017-10-25 18:42 GMT-03:00 Rob Crittenden  >:
> 
> Miguel Angel Coa M. wrote:
> > Hi Rob,
> > CN=LAB is a group entry and inside i've a few members
> >
> > [.]
> > # LAB, Users, example2.com  
> > dn: CN=LAB,CN=Users,DC=example2,DC=com
> > objectClass: top
> > objectClass: group
> > cn: LAB
> > description: Usuario de grupo LAB
> > member: CN=winuser64,CN=Users,DC=example2,DC=com
> > member: CN=winuserlab2 userlab2,OU=Test,DC=example2,DC=com
> > member: CN=winuser40 winuser40,OU=Test,DC=example2,DC=com
> > member: CN=winuserlab1 userlab1,OU=Test,DC=example2,DC=com
> > distinguishedName: CN=LAB,CN=Users,DC=example2,DC=com
> > instanceType: 4
> > whenCreated: 20171023203927.0Z
> > whenChanged: 20171024203108.0Z
> > uSNCreated: 49193
> > uSNChanged: 61493
> > name: LAB
> > objectGUID:: gQBcEwVqHU+L3DmmZPVFFw==
> > objectSid:: AQUAAAUVguTkYzspTdFQ0vfEWwQAAA==
> > sAMAccountName: LAB
> > sAMAccountType: 268435456
> > groupType: -2147483640
> > objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=example2,DC=com
> > dSCorePropagationData: 1601010100.0Z
> 
> That's why. winsync syncs against a subtree, not members of a group.
> 
> rob
> 
> > [.]
> >
> >
> > Regards.
> >
> >
> >
> >
> > Saludos.
> > ---
> > Miguel Coa M.
> >
> > 2017-10-25 17:28 GMT-03:00 Rob Crittenden  
> > >>:
> >
> > Miguel Angel Coa M. via FreeIPA-users wrote:
> > > Hello Everyone,
> > > I've setting IPA server connect with AD (Windows Server
> 2012R2) and work
> > > fine, but i need change the sub-tree for user sync and this
> step fail
> > > (not sync anything) .
> > > For example, when i sync against the default base is ok
> > >
> > > [.]
> > > CN=Users,DC=example2,dc=com
> > > [.]
> > >
> > > [.]
> > > nsds7WindowsReplicaSubtree: CN=Users,DC=example2,DC=com
> > > [.]
> > >
> > >
> > > But i try change the base and does not sync anything
> > >
> > > [.]
> > > CN=LAB,CN=Users,DC=example2,dc=com
> > > [.]
> > >
> > > When the LAB is AD group. ¿is possible sync against AD group?
> >
> > IIRC winsync looks for entries that match objectclass=ntuser.
> I CN=LAB
> > literally a group entry or a subtree?
> >
> > rob
> >
> >
> 
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Swiching which FreeIPA server is the main CA

[Kristian Petersen via FreeIPA-users]

I am having problems with the server that currently is my main CA and was
considering trying to switch that function to a different server.  I have
tried some of the stuff I found online but the CA role can't be enabled on
another server because it is broken on the one that has it right now.
Hence the operation fails.  Any other ideas on how to resolve this?  It is
OK if I have to abandon my old certificates and generate entirely new one
on the new CA server.

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