[Freeipa-users] Can't start dirsrv. Can't force reinitialize
ipactl startExisting service file detected!Assuming stale, cleaning and proceedingStarting Directory ServiceFailed to read data from service file: Failed to get list of services to probe status!Configured hostname this_server.domain' does not match any master server in LDAP: in /var/log/dirsrv/domain/errors [08/Mar/2017:14:13:04 +] NSMMReplicationPlugin - replica_check_for_data_reload: Warning: for replica o=ipaca there were some differences between the changelog max RUV and the database RUV. If there are obsolete elements in the database RUV, you should remove them using the CLEANALLRUV task. If they are not obsolete, you should check their status to see why there are no changes from those servers in the changelog.[08/Mar/2017:14:13:04 +] attrlist_replace - attr_replace (nsslapd-referral, ldap://other_replica.domain:389/o%3Dipaca) failed.[08/Mar/2017:14:13:04 +] attrlist_replace - attr_replace (nsslapd-referral, ldap://other_replica.domain:389/o%3Dipaca) failed.[08/Mar/2017:14:13:04 +] - slapd started. Listening on All Interfaces port 389 for LDAP requests[08/Mar/2017:14:13:04 +] - Listening on All Interfaces port 636 for LDAPS requests[08/Mar/2017:14:13:04 +] - Listening on /var/run/slapd-domain.socket for LDAPI requests[08/Mar/2017:14:13:04 +] agmt="cn=masterAgreement1other_replica.domain-pki-tomcat" (ipa-x2:389) - Can't locate CSN 55a420ef00040029 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.[08/Mar/2017:14:13:04 +] NSMMReplicationPlugin - changelog program - agmt="cn=masterAgreement1-other_replica.domain-pki-tomcat" (ipa-x2:389): CSN 55a420ef00040029 not found, we aren't as up to date, or we purged[08/Mar/2017:14:13:04 +] NSMMReplicationPlugin - agmt="cn=masterAgreement1-other_replica.domain-pki-tomcat" (other_replica:389): Data required to update replica has been purged. The replica must be reinitialized.[08/Mar/2017:14:13:04 +] NSMMReplicationPlugin - agmt="cn=masterAgreement1-other_replica.domain-pki-tomcat" (ipa-x2:389): Incremental update failed and requires administrator action when trying to force reinitialize [root@this_replica~]# ipa-replica-manage re-initialize --from=other_replica.domainipa: WARNING: session memcached servers not runningConnection timed out. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] replication breaks intermittently
[01/Mar/2017:18:19:48 +] agmt="cn=meTo ipa2.internal.domain" (ipa2:389) - Can't locate CSN 582301c3000d0077 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.[01/Mar/2017:18:19:48 +] NSMMReplicationPlugin - changelog program - agmt="cn=meToipa2.internal.domain" (ipa2:389): CSN 582301c3000d0077 not found, we aren't as up to date, or we purged[01/Mar/2017:18:19:48 +] NSMMReplicationPlugin - agmt="cn=meToipa2.internal.domain" (ipa2:389): Data required to update replica has been purged. The replica must be reinitialized.[01/Mar/2017:18:19:48 +] NSMMReplicationPlugin - agmt="cn=meToipa2.internal.domain" (ipa2:389): Incremental update failed and requires administrator action Seeing the above in the logs after seeing problems with replication. The data entered on one replica isn't making it to others. There are no problems with connectivity between the servers and all necessary ports are open. Currently we are getting around this problem by running a script to perform force sync. Any suggestions on the things that may be setup wrong to take a look at? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipactl services running, but auth not working
there are reports from multiple clients being unable to authenticate. ipactl status shows all services as running.The problem is fixed when I 'ipactl restart'. From: "Sullivan, Daniel [CRI]" <dsulliv...@bsd.uchicago.edu> To: pgb205 <pgb...@yahoo.com> Cc: Freeipa-users <freeipa-users@redhat.com> Sent: Friday, February 3, 2017 2:47 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working What exactly are you seeing to determine that the server is actually failing? Is it not possible that sssd (the client) is timing out? Will 389ds service an LDAP request, i.e. can you run ldapsearch -D "cn=Directory Manager" -w -s base -b "cn=config" "(objectclass=*)” What exactly are you trying to do? Just password authentication to an sssd client? Are you operating in a trusted AD environment? Dan On Feb 3, 2017, at 11:26 AM, pgb205 <pgb...@yahoo.com<mailto:pgb...@yahoo.com>> wrote: My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging From: "Sullivan, Daniel [CRI]" <dsulliv...@bsd.uchicago.edu<mailto:dsulliv...@bsd.uchicago.edu>> To: pgb205 <pgb...@yahoo.com<mailto:pgb...@yahoo.com>> Cc: Freeipa-users <freeipa-users@redhat.com<mailto:freeipa-users@redhat.com>> Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 <pgb...@yahoo.com<mailto:pgb...@yahoo.com><mailto:pgb...@yahoo.com<mailto:pgb...@yahoo.com>>> wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org <http://freeipa.org/> for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipactl services running, but auth not working
My problem is with the server itself seemingly not providing services even though it claims to do so. would be curious to know what to look at on freeipa server or how to inrease logging From: "Sullivan, Daniel [CRI]" <dsulliv...@bsd.uchicago.edu> To: pgb205 <pgb...@yahoo.com> Cc: Freeipa-users <freeipa-users@redhat.com> Sent: Thursday, February 2, 2017 5:16 PM Subject: Re: [Freeipa-users] ipactl services running, but auth not working Have you looked at the sssd logs yet? Dan On Feb 2, 2017, at 4:13 PM, pgb205 <pgb...@yahoo.com<mailto:pgb...@yahoo.com>> wrote: We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line. Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are: 1. What could be causing this, and what can I check. 2. What logging should I enable on the server. 3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up. What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron job that attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipactl services running, but auth not working
We have multiple ipa servers but only one is continuously affected by the strange problem described in the subject line.Users report not being able to login to servers that are using a specific ipa_server. Looking at this server ipactl shows everything as RUNNING. ipactl restart fixes the issue until the next time. My questions are:1. What could be causing this, and what can I check.2. What logging should I enable on the server.3. We are currently monitoring for processes 'Running' but clearly that is not fool-proof way to check if the service is actually up.What would be a definitive method to check if Freeipa is up and functional in all respects. I was thinking of setting up cron jobthat attempts to do kinit on a client machine. The problems that I foresee with this method is caching that might give false negatives. thanks-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unable to sudo with just one user on only a few servers
I have followed troubleshooting procedure outlined hereTroubleshooting - FreeIPA | | | | || | | | | | Troubleshooting - FreeIPA | | | | Additionally I have done contrast and compare with a working server for the following files/etc/hosts/etc/resolv.conf/etc/sudo-ldap.conf/etc/krb5.conf/etc/sssd.conf/etc/nssswitch.conf all are identical other than host specific information. In addition I have also enabled debug_level in sssd.conf in all stanzas, but noticed that sudo log is not being generated.I can however provide other logs. I have also enabled sudo_debug=2 in /etc/sudo-ldap.confbut not sure where to look for that log file. A and PTR records exist for problematic servers in FreeIPA DNS. As mentioned above the user-id can ssh just fine but not sudo for any command even though that id should be able to do ANY ANY. I have checked the the user-id is in the correct sudo groups that are applied for the host-groups for broken servers. To add to the oddity we somehow managed to fix the problem on several servers but as it was a lot blind trial and error we are not surewhat the corrective steps actually were. Please let me know what else I can/should take a look at. I can also provide logs if needed. thanks-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] down master still in ldap, prevents re-enrolement
topology prior to deletion master1<->master2 master2 deleted with ipa-server --uninstall command During re-installation I get error that the replication agreement still exists on master1.I do see this using ipa-replica-manage list. Tried deleting replication agreement withipa-replica-manage disconnect but receive 'no such replication agreement exist' Force deletion and cleanup do not workreceive unexpected error: Server is unwilling to perform: database is read-only removing directly from ldap gives me: ldapdelete -r -x -D "cn=Directory Manager" -W 'cn=fqdn,cn=masters,cn=ipa,cn=etc,dc=domain,dc=com' Enter LDAP Password:ldap_delete: Server is unwilling to perform (53)ldap_delete: Server is unwilling to perform (53) additional info: database is read-only But I am not sure if I'm not using correct path or if it's something else. Might be related to Bug 826677 – IPA cannot remove disconnected replica data to reconnect | | | Bug 826677 – IPA cannot remove disconnected replica data to reconnect | | | -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] is an IPA Server, but it might be unknown, foreign or previously deleted one
so initially the setup waswith ipa-server-03 having replication to ipa-server-02i have then decomissioned ipa-server-03 and setup a new one with the same name.right now replication is between ipa-server-03 and ipa-server-01 but i would want to add anotherreplication agreement 02 and 03 same as before but am getting the error message. All systems are centos 7 so I'd expect freeipa to be the latest version. From: Rob Crittenden <rcrit...@redhat.com> To: Martin Basti <mba...@redhat.com>; pgb205 <pgb...@yahoo.com>; Freeipa-users <freeipa-users@redhat.com> Sent: Friday, August 5, 2016 9:28 AM Subject: Re: [Freeipa-users] is an IPA Server, but it might be unknown, foreign or previously deleted one Martin Basti wrote: > > > On 05.08.2016 05:24, pgb205 wrote: >> my previous setup was >> srv2->replica >> srv1->srv2 >> >> I have removed replica and set it up with the one with identical hostname. >> Now I have replication from srv1->replica >> and am trying to create another agreement from srv2=>replica >> but i am getting the error message above. My guess is that old >> hostname is there somewhere >> but ipa-replica-manage del command does not produce any results. >> >> > > Hello, > > I don't see the error message you are referring This is an IPA 3.0 error message from ticket https://fedorahosted.org/freeipa/ticket/3105 What do you mean you removed it and setup an identical one? Did you do this with ipa-replica-install? ipa-replica-manage is looking up the masters and it doesn't consider replica a master which is why it is throwing this error. I'd double-check that replication is working properly. On each master run: ipa-replica-manage list -v `hostname` And really, ipa-replica-manage list should show a list of all known masters. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] is an IPA Server, but it might be unknown, foreign or previously deleted one
my previous setup wassrv2->replica srv1->srv2 I have removed replica and set it up with the one with identical hostname.Now I have replication from srv1->replica and am trying to create another agreement from srv2=>replica but i am getting the error message above. My guess is that old hostname is there somewherebut ipa-replica-manage del command does not produce any results.-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unable to add CA on an already configured replica
Current topology: ipa-srv1<->ipa-srv2 ipa-srv1 already has CA installed but NOT ipa-srv2. The reason I would like to add CA on ipa-srv2 is because I want the setup to ultimately become ipa-srv2<->ipa-srv2<->ipa-srv3 however I am unable to create gpg replication file on ipa-srv2 (to be used to establish replication agreement to ipa-srv3)as I get an error message: Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)From what I've found gpg can only be created on replica with CA installed. to install CA I tried the following commandipa-ca-install --skip-conncheck ./replica-info-ipa-srv2.gpg This errors out at [8/21]: starting certificate server instanceipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart the Dogtag instance.See the installation log for details. [9/21]: importing CA chain to RA certificate database [error] RuntimeError: Unable to retrieve CA chain: request failed with HTTP status 500 systemctl status pki-tomcatd@pki-tomcat.service shows the pki service is running, surprisingly. but it's still not listed in ipactl status output further attempts to install are halted with error : CA is already installed on this system and I have to manually delete everything with: pkidestroy -s CA -i pki-tomcat 1003 rm -rf /var/log/pki/pki-tomcat 1004 rm -rf /etc/sysconfig/pki-tomcat 1005 rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat 1006 rm -rf /var/lib/pki/pki-tomcat 1007 rm -rf /etc/pki/pki-tomcat in error logs the one message that stands out is:500 internal server error. which repeats multiple times at the end of log file. Please suggest on what can be done in this situation. PS: regarding pkidestroy and pkiremove commands. What is the difference or does pkidestroy superceeds pkiremove.Alexander B suggests pkiremove in one of his older posts and 'yum whatprovides pkiremove' also suggests that it should be available.-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Unable to ssh after establishing trust
thank you! that was it
From: Simpson Lachlan <lachlan.simp...@petermac.org>
To: pgb205 <pgb...@yahoo.com>; Sumit Bose <sb...@redhat.com>
Cc: Freeipa-users <freeipa-users@redhat.com>
Sent: Tuesday, July 19, 2016 7:30 PM
Subject: RE: Re: [Freeipa-users] Unable to ssh after establishing trust
#yiv1956000891 #yiv1956000891 -- _filtered #yiv1956000891
{font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv1956000891
{panose-1:2 11 6 9 7 2 5 8 2 4;} _filtered #yiv1956000891 {panose-1:2 11 6 9 7
2 5 8 2 4;} _filtered #yiv1956000891 {font-family:Calibri;panose-1:2 15 5 2 2 2
4 3 2 4;} _filtered #yiv1956000891 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4
4 2 4;} _filtered #yiv1956000891 {panose-1:2 11 6 9 7 2 5 8 2 4;}#yiv1956000891
#yiv1956000891 p.yiv1956000891MsoNormal, #yiv1956000891
li.yiv1956000891MsoNormal, #yiv1956000891 div.yiv1956000891MsoNormal
{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;}#yiv1956000891 a:link,
#yiv1956000891 span.yiv1956000891MsoHyperlink
{color:blue;text-decoration:underline;}#yiv1956000891 a:visited, #yiv1956000891
span.yiv1956000891MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}#yiv1956000891
span.yiv1956000891EmailStyle17
{color:windowtext;font-weight:normal;font-style:normal;}#yiv1956000891
span.yiv1956000891SpellE {}#yiv1956000891 .yiv1956000891MsoChpDefault
{font-size:10.0pt;} _filtered #yiv1956000891 {margin:72.0pt 72.0pt 72.0pt
72.0pt;}#yiv1956000891 div.yiv1956000891WordSection1 {}#yiv1956000891 From:
freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On
Behalf Ofpgb205
Sent: Wednesday, 20 July 2016 5:28 AM
To: Sumit Bose
Cc: Freeipa-users
Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
well...I'm not sure what I changed, if anything, but I am able to login with my
AD credentials. I have restarted ipa server and cleared sss_cache, so maybe
that helped. A few other things still remain though: right now im logging
in asjsmith@ADDOMAIN.LOCAL I would want it to be eitherjsm...@addomain.com or
better yet jsmith --without specifying the domain name. How can this be
accomplished? [Lachlan Simpson] You are looking for the
default_domain_suffix setting in the sssd stanza of /etc/sssd/sssd.conf
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/sssd-user-ids.html
CheersL. thanks From: Sumit Bose <sb...@redhat.com>
To: pgb205 <pgb...@yahoo.com>
Cc: Freeipa-users <freeipa-users@redhat.com>
Sent: Tuesday, July 19, 2016 3:33 AM
Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
>
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
>
> /etc/hosts:
> Reachable_IP_BOX 172.10.10.1
> DC1 172.10.10.1
> DC2 172.10.10.1
> ...
> ...
The IP address should come first, please see man hosts for details.
>
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'
Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?
>
>
> Additionally I have configured
> [domain/ipa.internal]
> with
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
>
>
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.
Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.
bye,
Sumit
>
>
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
>
> thanks
> ━━━
> From: Sumit Bose <sb...@redhat.com>
> To: pgb205 <pgb...@yahoo.com>
> Cc: Sumit Bose <sb...@redhat.com>; Freeipa-users <freeipa-users@redhat.com>
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> > From: pgb205 <pgb...@yahoo.com>
> > To: S
Re: [Freeipa-users] ipa trust-fetch-domains failing.
Alexander,
regarding your comment about putting stanza on each client.In our case clients
are not on the same network as the Active Directory domain controller.My plan
was to have the Freeipa server as the bridge-head server
AD DC <-> FIPA server <-> Linux clients
as it sits on the network that has access to both environments.
1. If each client has to go out to AD DC to authenticate than what is the
purpose of FreeIPA server ? I thought it would act as a proxy to forward
authentication requests to AD.
2. What would be my options in the above situation to get around this
requirement -- direct connectivity to Active Directoryenvironment by clients?
thanks
From: Alexander Bokovoy <aboko...@redhat.com>
To: pgb205 <pgb...@yahoo.com>
Cc: Freeipa-users <freeipa-users@redhat.com>
Sent: Monday, July 4, 2016 12:02 AM
Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
On Mon, 04 Jul 2016, pgb205 wrote:
>Selinux is disabled on the server. However, I managed to fix the problem buy
>adding the AD.DOMAIN {}
>section to my krb5.conf in addition to IPA.DOMAIN {}. So it now looks like
>[realms]IPA.DOMAIN{master_kdc=ipa.dc.ipadomain:portauth_kdc=ipa.dc.ipadomain:port...}
>AD.DOMAIN{master_kdc=ad.dc.addomain:portauth_kdc=ad.dc.addomain:port...}
>this had the desired effect although I am not 100 clear on why this worked.
>My theory is that we have multiple domain controllers and of course the
>addomain.com forward zone that was configured prior returns a full
>list. Only the ports to the one ad.dc.addomain.com server have been
>opened between the ipa and ad servers and so when trust command is
>executed connection goes to some domain controller that IPA can't
>connect to, eventually generating an error. Just a theory for now.
It is a totally plausible theory -- when we do trust-fetch-domains, we
try to use Kerberos authentication against AD DCs. Forcing IPA master to
use specific domain controller via krb5.conf should help here.
Note that you'll need to have a similar stanza on each IPA client as
well because authentication happens directly to AD DCs and SSSD on IPA
clients will have to do the same job using AD user credentials in case
of password logons.
>thanks
>
> From: Alexander Bokovoy <aboko...@redhat.com>
> To: pgb205 <pgb...@yahoo.com>
>Cc: "bentech4...@gmail.com" <bentech4...@gmail.com>; Freeipa-users
><freeipa-users@redhat.com>
> Sent: Friday, July 1, 2016 3:37 AM
> Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
>
>On Thu, 30 Jun 2016, pgb205 wrote:
>>Ben, do you mind sharing your solution as I am affected by the exact same
>>error when fetching AD domains.
>I'm currently on vacation and don't have access to my lab, but you need
>to check if there are any problems with SELinux. 'ipa
>trust-fetch-domains' calls out via DBus to another script. It is
>functionally equivalent to the following command run as root:
>
># oddjob_request -s com.redhat.idm.trust -o / -i com.redhat.idm.trust
>com.redhat.idm.trust.fetch_domains ad.test
>
>where ad.test is your AD root domain.
>
>If you add 'log level = 100' in /usr/share/ipa/smb.conf.empty, then this
>run will generate a lot of debug information.
>
>
>--
>/ Alexander Bokovoy
>
>
>
>--
>Manage your subscription for the Freeipa-users mailing list:
>https://www.redhat.com/mailman/listinfo/freeipa-users
>Go to http://freeipa.org for more info on the project
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Unable to ssh after establishing trust
well...I'm not sure what I changed, if anything, but I am able to login with my AD credentials. I have restarted ipa server and cleared sss_cache, so maybe that helped. A few other things still remain though: right now im logging in as jsmith@ADDOMAIN.LOCALI would want it to be either jsmith@ADDOMAIN.COMor better yetjsmith --without specifying the domain name. How can this be accomplished? thanks From: Sumit Bose <sb...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: Freeipa-users <freeipa-users@redhat.com> Sent: Tuesday, July 19, 2016 3:33 AM Subject: Re: [Freeipa-users] Unable to ssh after establishing trust On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote: > Sumit, > > I have set the names of all the Domain Controllers to be resolvable to the IP > of the one reachable Domain Controller in /etc/hosts > > /etc/hosts: > Reachable_IP_BOX 172.10.10.1 > DC1 172.10.10.1 > DC2 172.10.10.1 > ... > ... The IP address should come first, please see man hosts for details. > > However, I still see the following > Marking SRV lookup of service 'gc_addomain.local' as 'neutral' > Marking server dc1.addomain.local' as 'name not resolved' Have you tried to add the fully-qualified names (dc1.addomain.local) in the right format (see above) to /etc/hosts? > > > Additionally I have configured > [domain/ipa.internal] > with > subdomain_inherit = ldap_user_principal > ldap_user_principal = nosuchattr > > > As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be > the old hostname of the IPA KDC. > After much troubleshooting I believe I got this fixed by deleting extra > folders in > /var/named/dyndb-ldap/ipa/master > Right now the only two folders are ipa.internal and .in-addr.arpa. > I think this is what helped with this issue. but can you please confirm if it > sounds reasonable. Not sure how you got the additional directories but if on only have a single IPA DNS domain the two directories are sufficient. bye, Sumit > > > Ssh is still failing, possibly due to the problem 1 above. Is there anything > else I can do to force ipa to pay attention to the /etc/hosts ? > Or is this some other issue? > > thanks > ━━━ > From: Sumit Bose <sb...@redhat.com> > To: pgb205 <pgb...@yahoo.com> > Cc: Sumit Bose <sb...@redhat.com>; Freeipa-users <freeipa-users@redhat.com> > Sent: Wednesday, July 13, 2016 5:43 AM > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote: > > +freeipa-users list > > > > From: pgb205 <pgb...@yahoo.com> > > To: Sumit Bose <sb...@redhat.com> > > Sent: Tuesday, July 12, 2016 2:12 PM > > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > > > Sumit, thanks for replying > > So the first issue is my fault, probably from when I was sanitizing logs. > > our active directory domain is ad_domain.local, but users would expect to > login as userid@ad_domain.com or just userid.for ipa the kerberos realm is > IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal. > > ewr-fipa_server used to be old trial server so I am not sure why it's still > in the dns lookup results. I'll check this part further. > > Lastly. only the connection to one of the domain controllers on AD side is > open. As discussed previously with Alexandr BokovoyI forced, in > /etc/krb5.conf, > a connection to this single, accessible domain controller. Are there any other > files where I would needto lock down the connections between ipa->ad so that > all traffic goes to specific active directory domain controller? > > thanks again for replying so quickly. > > Currently it is not possible to specify individual AD DC SSSD on the IPA > server should talk to. We have ticket > https://fedorahosted.org/sssd/ticket/2599 to make this possible in some > later versions of SSSD. > > Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to > get a list of AD DC, then picks one to get the next nearest site for the > IPA domain and finally tries to lookup a DC from the matching site (if > any). > > According to your logs SSSD was able to find 18 DCs with the SRV lookup. > A call like > > dig SRV _ldap._tcp.ad_domain.local > > on the IPA server should return the same list of 18 DCs. > > As a work-around, or better a hack, you might want to try to set the IP > address of all the 18 DC returned to the IP address of the only > accessible DC in /etc/hosts. This way SSSD should have no chance to >
Re: [Freeipa-users] Unable to ssh after establishing trust
Sorry, I typed things out instead of copy/paste my etc hosts looks like: search ad.local127.0.0.1 localhost # The following lines are desirable for IPv6 capable hosts::1 localhost ip6-localhost ip6-loopbackff02::1 ip6-allnodesff02::2 ip6-allrouters 10.10.10.1 ipa_server.ipa.internal ipa_server172.19.10.10 ad_server1.ad.local172.19.10.10 ad_server2.ad.local172.19.10.10 ad_server3.ad.local If you want I can send you the sssd logs again From: Sumit Bose <sb...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: Freeipa-users <freeipa-users@redhat.com> Sent: Tuesday, July 19, 2016 3:33 AM Subject: Re: [Freeipa-users] Unable to ssh after establishing trust On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote: > Sumit, > > I have set the names of all the Domain Controllers to be resolvable to the IP > of the one reachable Domain Controller in /etc/hosts > > /etc/hosts: > Reachable_IP_BOX 172.10.10.1 > DC1 172.10.10.1 > DC2 172.10.10.1 > ... > ... The IP address should come first, please see man hosts for details. > > However, I still see the following > Marking SRV lookup of service 'gc_addomain.local' as 'neutral' > Marking server dc1.addomain.local' as 'name not resolved' Have you tried to add the fully-qualified names (dc1.addomain.local) in the right format (see above) to /etc/hosts? > > > Additionally I have configured > [domain/ipa.internal] > with > subdomain_inherit = ldap_user_principal > ldap_user_principal = nosuchattr > > > As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be > the old hostname of the IPA KDC. > After much troubleshooting I believe I got this fixed by deleting extra > folders in > /var/named/dyndb-ldap/ipa/master > Right now the only two folders are ipa.internal and .in-addr.arpa. > I think this is what helped with this issue. but can you please confirm if it > sounds reasonable. Not sure how you got the additional directories but if on only have a single IPA DNS domain the two directories are sufficient. bye, Sumit > > > Ssh is still failing, possibly due to the problem 1 above. Is there anything > else I can do to force ipa to pay attention to the /etc/hosts ? > Or is this some other issue? > > thanks > ━━━ > From: Sumit Bose <sb...@redhat.com> > To: pgb205 <pgb...@yahoo.com> > Cc: Sumit Bose <sb...@redhat.com>; Freeipa-users <freeipa-users@redhat.com> > Sent: Wednesday, July 13, 2016 5:43 AM > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote: > > +freeipa-users list > > > > From: pgb205 <pgb...@yahoo.com> > > To: Sumit Bose <sb...@redhat.com> > > Sent: Tuesday, July 12, 2016 2:12 PM > > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > > > Sumit, thanks for replying > > So the first issue is my fault, probably from when I was sanitizing logs. > > our active directory domain is ad_domain.local, but users would expect to > login as userid@ad_domain.com or just userid.for ipa the kerberos realm is > IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal. > > ewr-fipa_server used to be old trial server so I am not sure why it's still > in the dns lookup results. I'll check this part further. > > Lastly. only the connection to one of the domain controllers on AD side is > open. As discussed previously with Alexandr BokovoyI forced, in > /etc/krb5.conf, > a connection to this single, accessible domain controller. Are there any other > files where I would needto lock down the connections between ipa->ad so that > all traffic goes to specific active directory domain controller? > > thanks again for replying so quickly. > > Currently it is not possible to specify individual AD DC SSSD on the IPA > server should talk to. We have ticket > https://fedorahosted.org/sssd/ticket/2599 to make this possible in some > later versions of SSSD. > > Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to > get a list of AD DC, then picks one to get the next nearest site for the > IPA domain and finally tries to lookup a DC from the matching site (if > any). > > According to your logs SSSD was able to find 18 DCs with the SRV lookup. > A call like > > dig SRV _ldap._tcp.ad_domain.local > > on the IPA server should return the same list of 18 DCs. > > As a work-around, or better a hack, you might want to try to set the IP > address of all the 18 DC returned to the IP address of the only
Re: [Freeipa-users] Unable to ssh after establishing trust
Sumit, I have set the names of all the Domain Controllers to be resolvable to the IP of the one reachable Domain Controller in /etc/hosts /etc/hosts:Reachable_IP_BOX 172.10.10.1DC1 172.10.10.1DC2 172.10.10.1.. However, I still see the followingMarking SRV lookup of service 'gc_addomain.local' as 'neutral' Marking server dc1.addomain.local' as 'name not resolved' Additionally I have configured [domain/ipa.internal] with subdomain_inherit = ldap_user_principalldap_user_principal = nosuchattr As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be the old hostname of the IPA KDC.After much troubleshooting I believe I got this fixed by deleting extra folders in /var/named/dyndb-ldap/ipa/masterRight now the only two folders are ipa.internal and .in-addr.arpa. I think this is what helped with this issue. but can you please confirm if it sounds reasonable. Ssh is still failing, possibly due to the problem 1 above. Is there anything else I can do to force ipa to pay attention to the /etc/hosts ?Or is this some other issue? thanks From: Sumit Bose <sb...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: Sumit Bose <sb...@redhat.com>; Freeipa-users <freeipa-users@redhat.com> Sent: Wednesday, July 13, 2016 5:43 AM Subject: Re: [Freeipa-users] Unable to ssh after establishing trust On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote: > +freeipa-users list > > From: pgb205 <pgb...@yahoo.com> > To: Sumit Bose <sb...@redhat.com> > Sent: Tuesday, July 12, 2016 2:12 PM > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > Sumit, thanks for replying > So the first issue is my fault, probably from when I was sanitizing logs. > our active directory domain is ad_domain.local, but users would expect to > login as userid@ad_domain.com or just userid.for ipa the kerberos realm is > IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal. > ewr-fipa_server used to be old trial server so I am not sure why it's still > in the dns lookup results. I'll check this part further. > Lastly. only the connection to one of the domain controllers on AD side is > open. As discussed previously with Alexandr BokovoyI forced, in > /etc/krb5.conf, a connection to this single, accessible domain controller. > Are there any other files where I would needto lock down the connections > between ipa->ad so that all traffic goes to specific active directory domain > controller? > thanks again for replying so quickly. Currently it is not possible to specify individual AD DC SSSD on the IPA server should talk to. We have ticket https://fedorahosted.org/sssd/ticket/2599 to make this possible in some later versions of SSSD. Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to get a list of AD DC, then picks one to get the next nearest site for the IPA domain and finally tries to lookup a DC from the matching site (if any). According to your logs SSSD was able to find 18 DCs with the SRV lookup. A call like dig SRV _ldap._tcp.ad_domain.local on the IPA server should return the same list of 18 DCs. As a work-around, or better a hack, you might want to try to set the IP address of all the 18 DC returned to the IP address of the only accessible DC in /etc/hosts. This way SSSD should have no chance to connect to a different DC. bye, Sumit > > From: Sumit Bose <sb...@redhat.com> > To: pgb205 <pgb...@yahoo.com> > Cc: Sumit Bose <sb...@redhat.com> > Sent: Tuesday, July 12, 2016 5:37 AM > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote: > > Sumit, > > sssd log files attached with debug=10 in all sections.I have attempted > > several logins for comparison as well as kinit commands > > I came across two issues in the logs. > > First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt > but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the > AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently > FreeIPA cannot resolve those principals correctly. It was planned for > IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will > be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime > please try to work-around suggested at the end of > http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to > authenticate with user@AD_DOMAIN.COM SSSD looks for a server called > ewr-fipa_server.ad_domain.com but cannot find it an return the error code > for "Cannot contact any KDC for requested realm". > > Second there are some issues access AD DCs via LDAP. SSSD tries to > connect to mm-sfdc01.ad
Re: [Freeipa-users] Unable to ssh after establishing trust
+freeipa-users list From: pgb205 <pgb...@yahoo.com> To: Sumit Bose <sb...@redhat.com> Sent: Tuesday, July 12, 2016 2:12 PM Subject: Re: [Freeipa-users] Unable to ssh after establishing trust Sumit, thanks for replying So the first issue is my fault, probably from when I was sanitizing logs. our active directory domain is ad_domain.local, but users would expect to login as userid@ad_domain.com or just userid.for ipa the kerberos realm is IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal. ewr-fipa_server used to be old trial server so I am not sure why it's still in the dns lookup results. I'll check this part further. Lastly. only the connection to one of the domain controllers on AD side is open. As discussed previously with Alexandr BokovoyI forced, in /etc/krb5.conf, a connection to this single, accessible domain controller. Are there any other files where I would needto lock down the connections between ipa->ad so that all traffic goes to specific active directory domain controller? thanks again for replying so quickly. From: Sumit Bose <sb...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: Sumit Bose <sb...@redhat.com> Sent: Tuesday, July 12, 2016 5:37 AM Subject: Re: [Freeipa-users] Unable to ssh after establishing trust On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote: > Sumit, > sssd log files attached with debug=10 in all sections.I have attempted > several logins for comparison as well as kinit commands I came across two issues in the logs. First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently FreeIPA cannot resolve those principals correctly. It was planned for IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime please try to work-around suggested at the end of http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to authenticate with user@AD_DOMAIN.COM SSSD looks for a server called ewr-fipa_server.ad_domain.com but cannot find it an return the error code for "Cannot contact any KDC for requested realm". Second there are some issues access AD DCs via LDAP. SSSD tries to connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but both fails. It is not clear from the logs if already the DNS lookup for those fails or if the connection itself runs into a timeout. In the former case you should make sure that the names can be resolved in the IPA server in the latter you can try to increase ldap_network_timeout (see man sssd-ldap for details). Since SSSD cannot connect to the DCs it switches the AD domains to offline. The authentication request is handled offline as well but since there are no cached credentials you get the permission denied error. HTH bye, Sumit > > From: Sumit Bose <sb...@redhat.com> > To: pgb205 <pgb...@yahoo.com> > Cc: "Freeipa-users@redhat.com" <Freeipa-users@redhat.com> > Sent: Monday, July 11, 2016 3:06 AM > Subject: Re: [Freeipa-users] Unable to ssh after establishing trust > > On Mon, Jul 11, 2016 at 03:46:57AM +, pgb205 wrote: > > I have successfully established trust and am able to obtain ticket granting > > ticketkinit user@AD_DOMAIN.COMI can also do kinit admin@IPA_DOMAIN.COMssh > > admin@IPA_DOMAIN.COM also works > > however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails > > I have checked that there are no hbac rules other then the default > > allow_all rule > > in sssd_ssh.log see > > permission denied (6) error in sssd_ipa.domain.log file I see > > pam_handler_callback 6 permission_denied > > in sssd_nss.log Unable to get information from Data ProviderError: 3 > > Account info lookup failedWill try to return what we have in cache > > in /var/log/secure received for user user@AD_DOMAIN.COM: 6 (Permission > > denied) > > > > I can provided full logs if necessary to diagnose the above problem. > > Yes, full SSSD logs with debug_level=10 would be best. > > > --Additionally, I would like to be able to login as user not > > user@AD_DOMAIN.COM > > My understanding that only thing that I have to change to make this happen > > is /etc/krb5.conffor line > > [libdefaults] default_realm=AD_DOMAN.COM and then restarting ipa services. > > No, please do not change the default_realm. This is not related to the > issues you are seeing. > > bye, > Sumit > > > However, when I do this I get failure to restart Samba service > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > > -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unable to ssh after establishing trust
I have successfully established trust and am able to obtain ticket granting ticketkinit user@AD_DOMAIN.COMI can also do kinit admin@IPA_DOMAIN.COMssh admin@IPA_DOMAIN.COM also works however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails I have checked that there are no hbac rules other then the default allow_all rule in sssd_ssh.log see permission denied (6) error in sssd_ipa.domain.log file I see pam_handler_callback 6 permission_denied in sssd_nss.log Unable to get information from Data ProviderError: 3 Account info lookup failedWill try to return what we have in cache in /var/log/secure received for user user@AD_DOMAIN.COM: 6 (Permission denied) I can provided full logs if necessary to diagnose the above problem. --Additionally, I would like to be able to login as user not user@AD_DOMAIN.COM My understanding that only thing that I have to change to make this happen is /etc/krb5.conffor line [libdefaults] default_realm=AD_DOMAN.COM and then restarting ipa services. However, when I do this I get failure to restart Samba service-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa trust-fetch-domains failing.
Selinux is disabled on the server. However, I managed to fix the problem buy
adding the AD.DOMAIN {}
section to my krb5.conf in addition to IPA.DOMAIN {}. So it now looks like
[realms]IPA.DOMAIN{master_kdc=ipa.dc.ipadomain:portauth_kdc=ipa.dc.ipadomain:port...}
AD.DOMAIN{master_kdc=ad.dc.addomain:portauth_kdc=ad.dc.addomain:port...}
this had the desired effect although I am not 100 clear on why this worked.
My theory is that we have multiple domain controllers and of course the
addomain.com forward zone that was configured prior returns a full list. Only
the ports to the one ad.dc.addomain.com server have been opened between the ipa
and ad servers and so when trust command is executed connection goes to some
domain controller that IPA can't connect to, eventually generating an error.
Just a theory for now.
thanks
From: Alexander Bokovoy <aboko...@redhat.com>
To: pgb205 <pgb...@yahoo.com>
Cc: "bentech4...@gmail.com" <bentech4...@gmail.com>; Freeipa-users
<freeipa-users@redhat.com>
Sent: Friday, July 1, 2016 3:37 AM
Subject: Re: [Freeipa-users] ipa trust-fetch-domains failing.
On Thu, 30 Jun 2016, pgb205 wrote:
>Ben, do you mind sharing your solution as I am affected by the exact same
>error when fetching AD domains.
I'm currently on vacation and don't have access to my lab, but you need
to check if there are any problems with SELinux. 'ipa
trust-fetch-domains' calls out via DBus to another script. It is
functionally equivalent to the following command run as root:
# oddjob_request -s com.redhat.idm.trust -o / -i com.redhat.idm.trust
com.redhat.idm.trust.fetch_domains ad.test
where ad.test is your AD root domain.
If you add 'log level = 100' in /usr/share/ipa/smb.conf.empty, then this
run will generate a lot of debug information.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa trust-fetch-domains failing.
Ben, do you mind sharing your solution as I am affected by the exact same error when fetching AD domains. thanks On Sat, Apr 30, 2016 at 9:16 AM, Ben .T.George wrote: when i am running ipa trust-fetch-domains "kwttestdc.com.kw" , i am getting below error in error_log [Sat Apr 30 09:14:25.107449 2016] [:error] [pid 2666] ipa: ERROR: Failed to call com.redhat.idm.trust.fetch_domains helper.DBus exception is org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken..[Sat Apr 30 09:14:25.108353 2016] [:error] [pid 2666] ipa: INFO: [jsonserver_session] admin IDM LOCAL: trust_fetch_domains(u'kwttestdc.com.kw', rights=False, all=False, raw=False, version=u'2.156'): ServerCommandError On Sat, Apr 30, 2016 at 12:00 AM, Ben .T.George wrote: Hi Anyone please help me to fix this issue. i have created new group in AD( 4 hours back) and while i was mapping this group as --external, i am getting below error. [root freeipa sysctl.d]# ipa group-add --external ad_admins_external --desc "KWTTESTDC.com.KW AD Administrators-External"--Added group "ad_admins_external"-- Group name: ad_admins_external Description: KWTTESTDC.com.KW AD Administrators-External[root freeipa sysctl.d]# ipa group-add-member ad_admins_external --external "KWTTESTDC\test admins"[member user]:[member group]: Group name: ad_admins_external Description: KWTTESTDC.com.KW AD Administrators-External Failed members: member user: member group: KWTTESTDC\test admins: Cannot find specified domain or server name-Number of members added 0- On Fri, Apr 29, 2016 at 4:41 PM, Ben .T.George wrote: Hi while issuing ipa trust-fetch-domains, i am getting below error. i have created new security group in AD and i want to add this to external group. [root freeipa ~]# ipa trust-fetch-domains "kwttestdc.com.kw"ipa: ERROR: error on server 'freeipa.idm.local': Fetching domains from trusted fo rest failed. See details in the error_log help me to fi/expalin more about this error Regards -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Unable to add external group
Alexander, forwarding sanitized files to you privately From: Alexander Bokovoy <aboko...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: "Freeipa-users@redhat.com" <Freeipa-users@redhat.com> Sent: Tuesday, June 28, 2016 4:25 PM Subject: Re: [Freeipa-users] Unable to add external group On Tue, 28 Jun 2016, pgb205 wrote: >Trust is successfully established > >ipa trust-find---1 trust matched--- Realm name: >ad_domain.local Domain NetBIOS name: AD_DOMAIN >and I can get kerberos ticket and access to servicesKRB5_TRACE=/dev/stderr >kvno -S cifs ADDC.AD_DOMAIN >[3552] 1467143851.633980: Received creds for desired service >cifs/ADDC.AD_DOMAIN[3552] 1467143851.634008: Storing my_user@AD_DOMAIN -> >cifs/ADDC@AD_DOMAIN in >KEYRING:persistent:0:krb_ccache_02UjQwjcifs/ADDC.AD_DOMAIN: kvno = 29 >time is also correct and matches on both ipa and Domain Controller >When I go with the last few steps to add external AD group to the IPA >--external I get the followingipa group-add-member ad_domain_admins_external >--external 'AD_DOMAIN\Ops_Admins'[member user]:[member group]: Group name: >ad_domain_admins_external Description: ad_domain_admins external map Failed >members: member user: member group: AD_DOMAIN\Ops_Admins: trusted domain >object not found-Number of members added 0 >I have verified the Ops_Admins is readable by everyone in Active Directory. >In error_log I get >[:error] [pid 2619] ipa: INFO: [jsonserver_session] admin@IPA_DOMAIN: >group_add_member(u'ad_domain_admins_external', >ipaexternalmember=(u'AD_DOMAINOps_Admins',), all=False, raw=False, >version=u'2.156', no_members=False): SUCCESS >Any idea on what steps I'm missing or what other things to check ? If you have "trusted domain object not found", this means you don't really have trust established correctly. Unfortunately, sometimes we cannot get proper error message back to the user as Samba Python bindings don't give us much details. See http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust on how to generate proper debug logs for trust to see what is there. You kvno output is of no use -- obviously AD user would be able to obtain a ticket to AD DC's service, this is not a surprise. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unable to add external group
Trust is successfully established ipa trust-find---1 trust matched--- Realm name: ad_domain.local Domain NetBIOS name: AD_DOMAIN and I can get kerberos ticket and access to servicesKRB5_TRACE=/dev/stderr kvno -S cifs ADDC.AD_DOMAIN [3552] 1467143851.633980: Received creds for desired service cifs/ADDC.AD_DOMAIN[3552] 1467143851.634008: Storing my_user@AD_DOMAIN -> cifs/ADDC@AD_DOMAIN in KEYRING:persistent:0:krb_ccache_02UjQwjcifs/ADDC.AD_DOMAIN: kvno = 29 time is also correct and matches on both ipa and Domain Controller When I go with the last few steps to add external AD group to the IPA --external I get the followingipa group-add-member ad_domain_admins_external --external 'AD_DOMAIN\Ops_Admins'[member user]:[member group]: Group name: ad_domain_admins_external Description: ad_domain_admins external map Failed members: member user: member group: AD_DOMAIN\Ops_Admins: trusted domain object not found-Number of members added 0 I have verified the Ops_Admins is readable by everyone in Active Directory. In error_log I get [:error] [pid 2619] ipa: INFO: [jsonserver_session] admin@IPA_DOMAIN: group_add_member(u'ad_domain_admins_external', ipaexternalmember=(u'AD_DOMAINOps_Admins',), all=False, raw=False, version=u'2.156', no_members=False): SUCCESS Any idea on what steps I'm missing or what other things to check ? thanks-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can't establish trust with 2008 AD
OMAIN#1c (sitename (null))no entry for IPADOMAIN#1C found.resolve_lmhosts: Attempting lmhosts lookup for name IPADOMAIN<0x1c>resolve_lmhosts: Attempting lmhosts lookup for name IPADOMAIN<0x1c>getlmhostsent: lmhost entry: 127.0.0.1 localhostresolve_wins: WINS server resolution selected and no WINS servers listed.resolve_hosts: not appropriate for name type <0x1c>name_resolve_bcast: Attempting broadcast lookup for name IPADOMAIN<0x1c>tstream_unix_connect failed: No such file or directorynmbd not aroundAdding 0 DC's from auto lookupget_dc_list: no servers foundads_connect: No logon serverssitename_fetch: No stored sitename for IPADOMAINinternal_resolve_name: looking up dc.addomain.com#20 (sitename (null))name dc.addomain.com#20 found.remove_duplicate_addrs2: looking for duplicate address/port pairsads_try_connect: sending CLDAP request to 172.19.1.10 (realm: (null))ads_cldap_netlogon: did not get a replyads_try_connect: CLDAP request 172.19.1.10 failed.sitename_fetch: No stored sitename for IPADOMAINads_find_dc: (cldap) looking for domain 'IPADOMAIN'get_sorted_dc_list: attempting lookup for name IPADOMAIN (sitename NULL)saf_fetch: failed to find server for "IPADOMAIN" domainget_dc_list: preferred server list: ", *"internal_resolve_name: looking up IPADOMAIN#1c (sitename (null))no entry for IPADOMAIN#1C found.resolve_lmhosts: Attempting lmhosts lookup for name IPADOMAIN<0x1c>resolve_lmhosts: Attempting lmhosts lookup for name IPADOMAIN<0x1c>getlmhostsent: lmhost entry: 127.0.0.1 localhostresolve_wins: WINS server resolution selected and no WINS servers listed.resolve_hosts: not appropriate for name type <0x1c>name_resolve_bcast: Attempting broadcast lookup for name IPADOMAIN<0x1c>tstream_unix_connect failed: No such file or directorynmbd not aroundAdding 0 DC's from auto lookupget_dc_list: no servers foundads_connect: No logon serversDidn't find the cldap server!return code = -1 From: Alexander Bokovoy <aboko...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: "freeipa-users@redhat.com" <freeipa-users@redhat.com> Sent: Friday, June 10, 2016 1:58 AM Subject: Re: [Freeipa-users] Can't establish trust with 2008 AD On Fri, 10 Jun 2016, pgb205 wrote: >The trust setup still results in >Shared secret for the trust:: ERROR: CIFS server communication error: code >"None", message "NT_STATUS_IO_TIMEOUT" (both may be "None") >If you want I can provide with logs. Can you show output of net ads lookup -d 10 -S dc.addomain.com -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can't establish trust with 2008 AD
Sorry about replying privately. dig provides ipv4 addresses as expected. For example : r...@ipaserver.ipadomain.com:~# dig SRV _ldap._tcp.addomain.com#this is run on the FreeIPA where idm is installed as well as integrated DNS with the addomain.com stub zone that points to #dc.addomain.com;; QUESTION SECTION: ;_ldap._tcp.addomain.com. IN SRV ;; ANSWER SECTION:_ldap._tcp.addomain.com. 86400 IN SRV 0 100 389 dc.addomain.com. ;; AUTHORITY SECTION:addomain.com. 86400 IN NS ipadomain.com But just in case I have edited /etc/gai.conf with the following label ::1/128 0label ::/0 1label 2002::/16 2label ::/96 3label :::0:0/96 4precedence ::1/128 50precedence ::/0 40precedence 2002::/16 30precedence ::/96 20precedence :::0:0/96 100 and restarted ipa and dns ipactl stop/start and rndc reload The trust setup still results in Shared secret for the trust:: ERROR: CIFS server communication error: code "None", message "NT_STATUS_IO_TIMEOUT" (both may be "None") If you want I can provide with logs. thanks for the help From: Alexander Bokovoy <aboko...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: freeipa-users@redhat.com Sent: Friday, June 10, 2016 12:14 AM Subject: Re: [Freeipa-users] Can't establish trust with 2008 AD Please don't answer directly, use mailing list. On Thu, 09 Jun 2016, pgb205 wrote: >Alexander, > >As far as I can say ipv6 is enabled in the kernel, as the tutorial >suggests, although none of the interfaces have ipv6 addresses. > >For example, > ip a | grep inet6 > inet6 ::1/128 scope host > >and >ip -6 address show > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 > inet6 ::1/128 scope host > >root@:~# cat /proc/sys/net/ipv6/conf/all/disable_ipv6 >0 >root@:~# cat /proc/sys/net/ipv6/conf/default/disable_ipv6 >0 Does any of your DNS servers respond with IPv6 addresses for AD DCs? glibc DNS resolver prefers IPv6 over IPv4 in the default configuration and if that happens, without IPv6 routes it becomes unreachable. You can control how DNS resolver works with /etc/gai.conf (does not exist by default, see man page gai.conf for details) and can set IPv4 preference over IPv6 there, either globally or per host. > > > From: Alexander Bokovoy <aboko...@redhat.com> > To: pgb205 <pgb...@yahoo.com> >Cc: "Freeipa-users@redhat.com" <Freeipa-users@redhat.com> > Sent: Thursday, June 9, 2016 4:30 PM > Subject: Re: [Freeipa-users] Can't establish trust with 2008 AD > >On Thu, 09 Jun 2016, pgb205 wrote: >>The setup is:AD 2008 domain,Latest version of FreeIpa with integrated >>DNS,As the AD domain is not known to any DNS servers on the network I >>have created a stub zone in Freeipa integrated dns server >>addomain.com,and created A-record for DC.addomain.comas well as >>_ldap.tcp.addomain.com and _kerberos.udp.addomain.comand checked with >>dig that they resolve correctly, 138/139/145/389 are opened between the >>servers on both tcp and udp portsipv6 enabled on the FreeIpa server. I >>am using pre-shared secret to establish the trust >>Run:ipa trust-add --type=ad addomain.com --trust-secret >>and receive: >>ipa: ERROR: CIFS server communication error: code "None", >>message "NT_STATUS_IO_TIMEOUT" (both may be "None") >> >>I've enabled the logs as described in debugging section (I would be glad to >>forward the whole thing if needed)However, relevant error that I see is : >>finddcs: DNS SRV response 0 at ''finddcs: performing CLDAP >>query on s4_tevent: Added timed event "tevent_req_timedout": >>0x7f21302a8b10s4_tevent: Schedule immediate event "tevent_req_trigger": >>0x7f2130025090s4_tevent: Run immediate event "tevent_req_trigger": >>0x7f2130025090s4_tevent: Added timed event "tevent_req_timedout": >>0x7f213025cb90s4_tevent: Running timer event 0x7f213025cb90 >>"tevent_req_timedout"s4_tevent: Schedule immediate event >>"tevent_req_trigger": 0x7f2130045b50s4_tevent: Ending timer event >>0x7f213025cb90 "tevent_req_timedout"s4_tevent: Run immediate event >>"tevent_req_trigger": 0x7f2130045b50s4_tevent: Added timed event >>"tevent_req_timedout": 0x7f213025cb90s4_tevent: Running timer event >>0x7f213025cb90 "tevent_req_timedout"s4_tevent: Schedule immediate event >>"tevent_req_trigger": 0x7f213001d230s4_tevent: Ending timer event >>0x7f213025cb90 "tevent_req_timedout"s4_tevent: Run immediate event >>"tevent_req_trigger": 0x7f213001d230s
[Freeipa-users] Can't establish trust with 2008 AD
The setup is:AD 2008 domain,Latest version of FreeIpa with integrated DNS,As the AD domain is not known to any DNS servers on the network I have created a stub zone in Freeipa integrated dns server addomain.com,and created A-record for DC.addomain.comas well as _ldap.tcp.addomain.com and _kerberos.udp.addomain.comand checked with dig that they resolve correctly, 138/139/145/389 are opened between the servers on both tcp and udp portsipv6 enabled on the FreeIpa server. I am using pre-shared secret to establish the trust Run:ipa trust-add --type=ad addomain.com --trust-secret and receive: ipa: ERROR: CIFS server communication error: code "None", message "NT_STATUS_IO_TIMEOUT" (both may be "None") I've enabled the logs as described in debugging section (I would be glad to forward the whole thing if needed)However, relevant error that I see is : finddcs: DNS SRV response 0 at ''finddcs: performing CLDAP query on s4_tevent: Added timed event "tevent_req_timedout": 0x7f21302a8b10s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f2130025090s4_tevent: Run immediate event "tevent_req_trigger": 0x7f2130025090s4_tevent: Added timed event "tevent_req_timedout": 0x7f213025cb90s4_tevent: Running timer event 0x7f213025cb90 "tevent_req_timedout"s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f2130045b50s4_tevent: Ending timer event 0x7f213025cb90 "tevent_req_timedout"s4_tevent: Run immediate event "tevent_req_trigger": 0x7f2130045b50s4_tevent: Added timed event "tevent_req_timedout": 0x7f213025cb90s4_tevent: Running timer event 0x7f213025cb90 "tevent_req_timedout"s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f213001d230s4_tevent: Ending timer event 0x7f213025cb90 "tevent_req_timedout"s4_tevent: Run immediate event "tevent_req_trigger": 0x7f213001d230s4_tevent: Added timed event "tevent_req_timedout": 0x7f213025cb90s4_tevent: Running timer event 0x7f21302a8b10 "tevent_req_timedout"s4_tevent: Destroying timer event 0x7f213025cb90 "tevent_req_timedout"finddcs: No matching CLDAP server founds4_tevent: Ending timer event 0x7f21302a8b10 "tevent_req_timedout"[Thu Jun 09 20:39:38.703506 2016] [:error] [pid 2503] ipa: INFO: [jsonserver_session] admin@: trust_add(u'addomain.com', trust_type=u'ad', trust_secret=u'', all=False, raw=False, version=u'2.156'): RemoteRetrieveError Once again I would be glad to provide entire logs if needed. But would be grateful for suggestions on how to resolve the above error.-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Forcing passync to periodically sync passwords
Alexander, thank you for such a quick reply. The reason im looking at this is that I want to synchronize from AD to several FIPA domains, but as you mention it's only1-1 passync option. This results in my not being able to synchronize passwords to second idm domain. Other options I've considered are:1. Run multiple instances of passsync on each DC. Both will intercept password change but will send to different ipa replicas in different freeipa domains. >From this link it doesn't seem to be possible however#48174 (RFE: Support for >running multiple instances of the PassSync service) – 389 Project | | | | || | | | | | #48174 (RFE: Support for running multiple instances of the PassSync service... | | | | 2. backing up/copying freeipa database that does have user/pass to second idm domainThis is not something I'm looking to do but if there is no other way I'd be willing to consider somehow grabbing files from ipa-repplica.domain.comand moving to ipa-server.example.net. Is this a route that's even worth looking into ? Any other options that you are aware of to make this setup possible. 1AD->FIPA1.com ->FIPA2.comwith password replication to both? thanks From: Alexander Bokovoy <aboko...@redhat.com> To: pgb205 <pgb...@yahoo.com> Cc: Freeipa-users <freeipa-users@redhat.com> Sent: Tuesday, May 24, 2016 12:22 PM Subject: Re: [Freeipa-users] Forcing passync to periodically sync passwords On Tue, 24 May 2016, pgb205 wrote: >Currently passync is only triggered one the domain controller where the >password change is made.Is there a way to trigger passync to run >periodically and resend information to freeipa even if there are no >changes? Passsync implements an interface on AD DC side that is activated only when AD user changes the password. There is no way to access clear text password at other time. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Forcing passync to periodically sync passwords
Currently passync is only triggered one the domain controller where the password change is made.Is there a way to trigger passync to run periodically and resend information to freeipa even if there are no changes?-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Advise on the best way to configure the following
We have:AD->winsync->FIPA1<->replica<->FIPA2etc to multiple other replicas from FIPA1 What we want is to establish separate set of FIPA replicas which wold still have information from AD and yet would not 'pollute' the FIPA1/FIPA2 replicas above. So far we have considered following options:1. Set up new FIPA3 replica to grab its information from FIPA1.This didn't work as two-way-trust would replicate 'bad' information from FIPA3 back to FIPA1/2 2. One way trust between replicas.Somehow establish one way replication from FIPA1->FIPA3. 'Good' information gets to FIPA3. But new additions on FIPA3 won't make it back to 'clean' environment.From reading posts on the list this is impossible. 3. Setup separate winsync 'channels' from AD directly to FIPA3. Ie AD->winsync->FIPA3.The problem with this is winsync of user accounts is possible, but password sync requires there to be only one point of contact between AD domain and FIPA domain.That is all AD controllers contact one and only one FIPA controller using passsync utility. So there is no way (if I understand correctly) to do:AD->sync->FIPA1 ->sync->FIPA3 If my understanding above is correct what would be the correct way of setting up separate FIPA environments, sourced from the same AD domain and to replicate both users and passwords? thanks-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Unable to authenticate
I have enabled debugging withdebug_level = 7 in sssd.conf Receive following error messages:Marking server 'ipa-server' as 'name resolved'[be_resolve_server_process] (0x0200): Found address for server ipa-server [get_port_status] (0x1000): Port status of port 389 for server 'ipa-server' is 'not working' telnet ipa-server 389 works so it's not a problem with name resolution or ports being blocked in krb5.conf i do have entries for ipa-server as well. The logs also claim that the server is offline, but that's of course is not the root cause. Are there any other things that I'm missing. Or what would you suggest as next troubleshooting step? thanks-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
