Re: [Freeipa-users] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Chris Dagdigian]

Standa Laznicka wrote:
You can, but you probably won't be able to install a CA replica on 
them (you have to leave out the --setup-ca option). In the meantime, 
you can create replicas without CA replication and when the Dogtag/DS 
guys solve the problem, you can run ipa-ca-install on those to setup 
CA replication there as well. 


Appreciate the attention this is getting!

My testing from yesterday shows that all replication is broken for me 
due to this 'replication manager' user not existing in LDAP so I may be 
hit by something in addition to the dogtag issue


I have two  servers that are out of sync with each other

 - Manual force update fails
 - Manual re-initialization fails
 - Installing a new IPA server without CA-service claims to work but no 
actual updates transfer


As far as I can tell all of the failures are due to an LDAP access issue 
where the logs talk about a replication-agreement-specific LDAP user not 
existing.


Example From Replica:

# ipa-replica-manage -v re-initialize --from usaeilidmp001.redactedidm.org
ipa: INFO: Setting agreement 
cn=meTousaeilidmp002.redactedidm.org,cn=replica,cn=dc\=redactedidm\,dc\=org,cn=mapping 
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement 
cn=meTousaeilidmp002.redactedidm.org,cn=replica,cn=dc\=redactedidm\,dc\=org,cn=mapping 
tree,cn=config

Update in progress, 14 seconds elapsed

# [usaeilidmp001.redactedidm.org] reports: Update failed! Status: [-2  - 
LDAP error: Local error]




dirsirv error logs from Master:

04/May/2017:12:20:08.531621754 +] slapi_ldap_bind - Error: could not 
bind id [cn=Replication Manager 
cloneAgreement1-usaeilidmp002.redactedidm.org-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 
(Success)
[04/May/2017:12:20:10.071619724 +] slapi_ldap_bind - Error: could 
not bind id [cn=Replication Manager 
cloneAgreement1-deawilidmp001.redactedidm.org-pki-tomcat,ou=csusers,cn=config] 
authentication mechanism [SIMPLE]: error 32 (No such object) errno 0 
(Success)
[04/May/2017:12:20:11.074340742 +] set_krb5_creds - Could not get 
initial credentials for principal [ldap/usaeilidmp001.redactedidm.org@] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not 
found)
[04/May/2017:12:20:35.078730934 +] set_krb5_creds - Could not get 
initial credentials for principal [ldap/usaeilidmp001.redactedidm.org@] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not 
found)
[04/May/2017:12:21:23.083737475 +] set_krb5_creds - Could not get 
initial credentials for principal [ldap/usaeilidmp001.redactedidm.org@] 
in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328203 (Key table entry not 
found)






Regards,
Chris



--
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 make replica with CA due to LDAP 'replication manager' user not found error

[Chris Dagdigian]

Florence Blanc-Renaud wrote:

the issue looks similar to ticket 6766 [1]
Flo.

[1] https://pagure.io/freeipa/issue/6766



Thanks Flo, I agree that this looks like the issue I"m hitting in v4.4 
much appreciated!


I'm gonna be watching this closely, it's nerve wracking knowing that I 
can't use, update or create *any* replica servers at the moment ...


-Chris


--
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] Can't make replica with CA due to LDAP 'replication manager' user not found error

[Chris Dagdigian]

Any guidance for this one?

Summary - this seems to be the fatal error that causes the CA setup on 
the replica to fail:


May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection: 
The specified user cn=Replication Manager 
masterAgreement1-usaeilidmp002.XXX.org-pki-tomcat,cn=config does not exist



May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init(): 
password test execution failed for replicationdbwith NO_SUCH_USER.  This 
may not be a latest instance.  Ignoring ..



More details ...


Trying to build a replica with CA duties for the first time.

It hangs here during the replica install process:


ipa : DEBUGstderr=
ipa : DEBUGwait_for_open_ports: localhost [8080, 8443] 
timeout 300

ipa : DEBUGWaiting until the CA is running
ipa : DEBUGrequest POST 
http://usaeilidmp002.XXX.org:8080/ca/admin/ca/getStatus

ipa : DEBUGrequest body ''


However the root cause seems to be that the CA won't start because 
something is wrong with an LDAP replication manager user?


When I restart the pki-tomcatd service the replica install STDOUT 
refreshes the above status. After the 3rd attempt it triggers the fatal 
"CA will not start after 300 seconds" error




From the logs:

# systemctl status pki-tomcatd@pki-tomcat.service
● pki-tomcatd@pki-tomcat.service - PKI Tomcat Server pki-tomcat
   Loaded: loaded (/lib/systemd/system/pki-tomcatd@.service; enabled; 
vendor preset: disabled)

   Active: active (running) since Wed 2017-05-03 15:09:04 UTC; 40s ago
  Process: 3843 ExecStop=/usr/libexec/tomcat/server stop (code=exited, 
status=1/FAILURE)
  Process: 3880 ExecStartPre=/usr/bin/pkidaemon start %i (code=exited, 
status=0/SUCCESS)

 Main PID: 3993 (java)
   CGroup: 
/system.slice/system-pki\x2dtomcatd.slice/pki-tomcatd@pki-tomcat.service
   └─3993 /usr/lib/jvm/jre-1.8.0-openjdk/bin/java 
-DRESTEASY_LIB=/usr/share/java/resteasy-base 
-Djava.library.path=/usr/lib64/nuxwdog-jni -classpath /usr/share/...


May 03 15:09:08 usaeilidmp002.XXX.org server[3993]: 
SSLAuthenticatorWithFallback: Setting container
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
SSLAuthenticatorWithFallback: Initializing authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
SSLAuthenticatorWithFallback: Starting authenticators
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
CMSEngine.initializePasswordStore() begins
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
CMSEngine.initializePasswordStore(): tag=internaldb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection 
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: 
CMSEngine.initializePasswordStore(): tag=replicationdb
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection 
connecting to usaeilidmp002.XXX.org:389
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: testLDAPConnection: 
The specified user cn=Replication Manager 
masterAgreement1-usaeilidmp002.XXX...not exist
May 03 15:09:09 usaeilidmp002.XXX.org server[3993]: CMSEngine: init(): 
password test execution failed for replicationdbwith NO_SUCH_USER.  This 
may not...noring ..

Hint: Some lines were ellipsized, use -l to show in full.






--
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] Simple replica debugging? Different Host count between replicating masters ...

[Chris Dagdigian]

I have a simple IPA setup with masters spanning two different AWS 
regional VPCs with a replication agreement between them.


Oddly enough I see a different host count between the two servers.

I've tried running:

ipa-replica-manage force-sync --from (remote host)

... on both hosts. Did not seem to work but also produced no real error 
output.


Example:

# ipa-replica-manage force-sync --verbose --from deawilidmp001.XXX.org
ipa: INFO: Setting agreement 
cn=meTousaeilidmp001.XXX.org,cn=replica,cn=dc\=XXX\,dc\=org,cn=mapping 
tree,cn=config schedule to 2358-2359 0 to force synch
ipa: INFO: Deleting schedule 2358-2359 0 from agreement 
cn=meTousaeilidmp001.XXX.org,cn=replica,cn=dc\=XXX\,dc\=org,cn=mapping 
tree,cn=config



Any useful hints or tips for troubleshooting? Normally I'd blow a master 
away and recreate a replica server but the replica that is misbehaving 
has "more" enrolled Hosts than the master I wish to preserve ...


Regards,
Chris


--
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] any tips or horror stories about automating dynamic enrollment and removal of IPA clients?

[Chris Dagdigian]

Hah! I've been deep into 
SGE (user, trainer, consultant) for years. 

Our setups are pretty similar but I'm hoping to use the AWS cfnCluster 
stack (https://github.com/awslabs/cfncluster) because it is officially 
blessed by AWS and since it's a cloudformation template at the end of 
the day it's both easy to support and extend. It also does all the hard 
work (auto-scaling etc.) that I don't want to have to code myself via 
ansible. Since I'm a consultant I need to hand off something to my users
 that is easy for them to operate moving forward without me. 

Your experience using IPA in an HPC environment is very helpful. We also
 use ansible to automate "ipa-client-install --unattended ..." so 
scripting the install and remove commands should be pretty 
straightforward. 
  
Just trying to my compare my  appreciation for IPA vs what I saw on the 
ground at massive HPC installations where the operators jumped through 
hoops to remove network services that could break user info or affect 
stablity. I lost count of how many sites I saw people dumping NIS maps 
and LDAP directories into plaintext files every 4-6hours that they'd 
spread across the cluster simply to remove any chance that a failed 
NIS/LDAP query could mess up a node, user or job. 
  
Thanks!
  
Chris
  


 
   	Gerald-Markus ZabosApril
 13, 2017 at 9:21 AM
  Hi Chris,we're
 facing a similar use case from day to day, but changed from AWS toanother
 cloud provider. Our use case works on both, so i am refering toAWS.We
 decided..to use SGE for our HPC infrastructure...recycle
 network ranges for 100 static IP addresses + 100 statichostnames...to
 use scripts & cronjobs & ansible (depending on "qstat" and 
"qhost"output) on the cluster head node to determine how many 
additionalcluster nodes have to be created as an additional reserve 
for"What-if-we-need-more-nodes?" scenarios...to create cluster 
nodes via ansible-playbook on AWS from apre-defined image, do 
software installation & configuration viaansible-playbook, do 
the IPA domain join via ansible-playbook("ipa-client-install 
--domain= --mkhomedir--hostname=.
 --ip-address=address> -p  
-w  --unattended")...to destroy cluster 
nodes in two steps: 1) ansible-playbook"ipa-client-install 
--uninstall", 2) ansible-playbook destroy clusternode on AWS via API(Right
 now, i am working on a bulk creation script of IPA users/groupsfor 
expanding our single HPC cluster into several ones, whereas we havethe
 same set of users (~65-100) with differing suffix in the usernamee.g.
 "it_ops01", "it_ops20", etc...)We're using 2x IPA-Servers (ESXi
 VMs, 4GB RAM, 2 CPU) in replicationwith another 2x IPA Servers 
(same dimensions) on our main physicaldatacenter. Didn't see much 
impact on the IPA servers duringenrollment/removal of domain hosts. 
So far after three months ofoperations, we had several "bad box" 
scenarios, all of them because ofproblems with SGE. We solved these 
problems manually, by removing/addingcluster nodes via SGE commands.
 As you can see, i tend to [Option 1], since it does all the 
magic withpre-defined software commands(sge, ansible, ipa cli), 
instead of jumpingaround with additional scripts doing work, which 
can be done by"built-in" commands. For us, this works best.Regards,Gerald




-- 
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] any tips or horror stories about automating dynamic enrollment and removal of IPA clients?

[Chris Dagdigian]

Hi folks,

I've got a high performance computing (HPC) use case that will need AD 
integration for user identity management. We've got a working IPA server 
in AWS that has 1-way trusts going to several remote AD forests and 
child domains. Works fine but so far all of the enrolled clients are 
largely static/persistent boxes.


The issue is that the HPC cluster footprint is going to be elastic by 
design. We'll likely keep 3-5 nodes in the grid online 24x7 but the vast 
majority of the compute node fleet (hundreds of nodes quite likely) will 
be fired up on demand as a mixture of spot, RI and hourly-rate EC2 
instances. The cluster will automatically shrink in size as well when 
needed.


Trying to think of which method I should use for managing users  (mainly 
UID and GID values) on the compute fleet:


[Option 1]  Script the enrollment and de-install actions via existing 
hooks we have for running scripts at "first boot" as well as 
"pre-termination".  I think this seems technically pretty 
straightforward but I'm not sure I really need to stuff our IPA server 
with host information for boxes that are considered anonymous and 
disposable. We don't care about them really and don't need to implement 
RBAC controls on them. Also slightly worried that a large-scale 
enrollment or uninstall action may bog down the server or (worse) 
perhaps only partially complete leading to an HPC grid where jobs flow 
into a bad box and die en-mass because "user does not exist..."


[Option 2]  Steal from the HPC ops playbook and minimize network 
services that can cause failures. Distribute static files to the worker 
fleet --  Bind the 24x7 persistent systems to the IPA server and force 
all HPC users to provide a public SSH key. Then use commands like "id 

[Freeipa-users] strange error when running "ipa help topics"

[Chris Dagdigian]

  
Never seen this one before,  any hints? 
  
  testidm]# ipa help topics
  ipa: ERROR: error marshalling 
data for XML-RPC transport: message: need a ; got 
'No valid Negotiate header in server response' (a )
  
-Chris


  
  



-- 
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] Fwd: Marking subdomain offline

[Chris Dagdigian]

I see similar things in our environment where IPA is used as "glue" 
between AD Forests that have a 1-way trust relationship. We believe that 
the root cause has something to do with the 30+ domain controllers the 
IPA client tries to make contact with (in seemingly random order) across 
the AD Forest.  Very hard to reproduce but the "subdomain marked 
offline" problem is one we see often in the sssd logs. We think that 
there are some AD servers in our sprawling environment that we either 
can't reach properly over the network (firewalls, etc.) or are just 
plain not configured to talk properly to us.  Login success depends on 
hitting a happy domain controller.


We are VERY interested in the recent updates to IPA server that seem to 
indicate we can 'pin" clients to certain specific AD controllers and 
from my understanding we just need to wait until the SSSD software gets 
broad support for this feature as well. Once we can do that we plan to 
pin our clients to named controllers and see if that helps with any of 
the intermittent login problems.


One workaround we've started to use for power users is collecting public 
SSH keys and hosting them in the IPA server -- as long as IPA knows that 
the user "exists" in AD and has a roughly complete group membership list 
than logging in with SSH key instead of AD password bypasses the 
transient password checking failures and is very quick.


Chris


m...@chinewalking.com 
April 6, 2017 at 1:21 PM
Hi,

My IPA<->AD trust setup experiences intermittent failures during login 
events. The AD subdomain goes in an inactive/offline state and users 
logging in are put into a 'delayed authentication' queue. Usually 
logging in after a minute or so succeeds as the subdomain is reset and 
the user is cached for following events. At all times getent/id and 
kinit's are succesfull, even with a purged sssd cache.

SRV records are correctly resolved, except for _kerberos-master.

I have not been able to further troubleshoot the intermittent 
failures. Traffic captures show no strange behaviour, yet the 
sssd_domain log is clearly showing AD to be unreachable at times. All 
AD servers are W2012 and DNS masking _ldap and _kerberos to single 
nodes, factoring out any faulty Windows configs, so far has not had 
any effect (Would it?).


sssd's data_provider_fo.c :> be_fo_reset_svc() calls fo_get_service(), 
which returns EOK. I'm not familiar yet with the variables at play, 
would adding debug statements here reveal faults that may cause this?


Any pointers are very much appreciated.

Mike


[sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_step] (0x0400): 
Looking up AD account
[sssd[be[unix.foo.local]]] [ipa_srv_ad_acct_lookup_done] (0x0080): 
Sudomain lookup failed, will try to reset sudomain..
[sssd[be[unix.foo.local]]] [ipa_server_trusted_dom_setup_send] 
(0x1000): Trust direction of subdom foo.local from forest foo.local 
is: one-way inbound: local domain trusts the remote domain
[sssd[be[unix.foo.local]]] [ipa_server_trusted_dom_setup_1way] 
(0x0400): Will re-fetch keytab for foo.local
[sssd[be[unix.foo.local]]] [ipa_getkeytab_send] (0x0400): Retrieving 
keytab for UNIX$@FOO.local from ipa01.unix.foo.local into 
/var/lib/sss/keytabs/foo.local.keytab6AXxWV using ccache 
/var/lib/sss/db/ccache_UNIX.FOO.local
[sssd[be[unix.foo.local]]] [child_handler_setup] (0x2000): Setting up 
signal handler up for pid [6242]
[sssd[be[unix.foo.local]]] [child_handler_setup] (0x2000): Signal 
handler set up for pid [6242]
[sssd[be[unix.foo.local]]] [sdap_process_result] (0x2000): Trace: 
sh[0x7f71cd9ddb80], connected[1], ops[(nil)], ldap[0x7f71cd9e65a0]
[sssd[be[unix.foo.local]]] [sdap_process_result] (0x2000): Trace: end 
of ldap_result list
[sssd[be[unix.foo.local]]] [ad_online_cb] (0x0400): The AD provider is 
online
[sssd[be[unix.foo.local]]] [be_ptask_online_cb] (0x0400): Back end is 
online
[sssd[be[unix.foo.local]]] [be_ptask_enable] (0x0080): Task 
[Subdomains Refresh]: already enabled
Keytab successfully retrieved and stored in: 
/var/lib/sss/keytabs/foo.local.keytab6AXxWV
[sssd[be[unix.foo.local]]] [child_sig_handler] (0x1000): Waiting for 
child [6242].
[sssd[be[unix.foo.local]]] [child_sig_handler] (0x0100): child [6242] 
finished successfully.
[sssd[be[unix.foo.local]]] [ipa_getkeytab_recv] (0x2000): 
ipa-getkeytab status 0
[sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): 
Keytab successfully retrieved to 
/var/lib/sss/keytabs/foo.local.keytab6AXxWV
[sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x2000): 
Keytab renamed to /var/lib/sss/keytabs/foo.local.keytab
[sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): 
Keytab /var/lib/sss/keytabs/foo.local.keytab6AXxWV contains the 
expected principals
[sssd[be[unix.foo.local]]] [ipa_server_trust_1way_kt_done] (0x0400): 
Established trust context for foo.local
[sssd[be[unix.foo.local]]] [unique_filename_destructor] (0x2000): 
Unlinking 

Re: [Freeipa-users] replica install seems to hang forever when "--setup-ca" is enabled - any advice?

[Chris Dagdigian]

That looks exactly like my issue, thanks! Will monitor that ticket. Much 
appreciated.


Martin Basti wrote:


Could it be this?
https://pagure.io/freeipa/issue/6766



--
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] replica install seems to hang forever when "--setup-ca" is enabled - any advice?

[Chris Dagdigian]

Any tips for diving into this a bit more to troubleshoot?

For the 1st time I'm setting up an ipa-server 4.4 replica with CA 
features enabled but the replica install seems to hang forever here:


...
...
...
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 
30 seconds

  [1/27]: creating certificate server user
  [2/27]: configuring certificate server instance
  [3/27]: stopping certificate server instance to update CS.cfg
  [4/27]: backing up CS.cfg
  [5/27]: disabling nonces
  [6/27]: set up CRL publishing
  [7/27]: enable PKIX certificate path discovery and validation
  [8/27]: starting certificate server instance

< no output after this >


The replica-install.log file ends here:

...
...
...
2017-03-15T22:16:05Z DEBUG Starting external process
2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active 
pki-tomcatd@pki-tomcat.service

2017-03-15T22:16:05Z DEBUG Process finished, return code=0
2017-03-15T22:16:05Z DEBUG stdout=active

2017-03-15T22:16:05Z DEBUG stderr=
2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443] 
timeout 300

2017-03-15T22:16:06Z DEBUG Waiting until the CA is running
2017-03-15T22:16:06Z DEBUG request POST 
http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus

2017-03-15T22:16:06Z DEBUG request body ''




I've confirmed that SELINUX is disabled, there is no firewall and the 
AWS Security Groups are allowing TCP:8080 and TCP:8443 to the replica 
instance. The systemctl command also verifies that

pki-tomcatd@pki-tomcat.service is "active" as well.


Any tips for debugging further?


Regards,
Chris


--
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] Can too many group memberships for an AD user cause SSSD or IPA problems?

[Chris Dagdigian]

I've got a case where "id @AD-DOMAIN" hangs forever after 
partially resolving and I think it may because they are in way too many 
AD groups?


The 'id' command resolve the user but hangs before completing. There is 
a large amount of group data returned from the AD forest for this user 
and the 'id' command seems to pause/hang right at the 3024th character 
returned.


Looking for pointers / tips. I'm thinking the AD user is in way too many 
groups but I don't know if this is a real limit or what the limit may 
be.  Any other reason why an 'id' command may start to work but hang 
before completion for an AD-defined user?


Regards,
Chris



--
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] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error

[Chris Dagdigian]

Update:

Resolved.  A bit of googling led me to some good RHEL pages as well as 
mailing list messages from Alex B that were concise and helpful.


To summarize for others who may have this problem:

1. Don't make changes to sssd.conf if your provider is "ipa" - in this 
case you work only with "ipa idrange-mod" type commands or webUI


2. The simple solution is to increase the range and restart SSSD after 
blowing away out of date sssd  database:


# ipa idrange-mod --base-id=400 --range-size=100 
EAME.COMPANY.ORG_id_range

# service sssd stop; rm -f /var/lib/sss/db/*; service sssd start


What I actually did on our IPA server was a bit more expansive. EAME was 
the first child domain where I had the SID to UID map issue but it would 
probably not have been the only one so I figured it would be safer to 
make sure that every child domain range had at least 1 million available 
IDs


Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name"

I went through every single AD child domain and manually reconfigured 
both the "First Posix ID of the range" as well as "Number of IDs in the 
range" so we have at least 1,000,000 ID options in each child domain range:


APAC.COMPANY.ORG   1st-Posix=18   Ids-in-range: 100
EAME.COMPANY.ORG   1st-Posix=181000   Ids-in-range: 100
LATAM.COMPANY.ORG  1st-Posix=182000   Ids-in-range: 100
NAFTA.COMPANY.ORG  1st-Posix=183000   Ids-in-range: 100

We are still in testing mode with less than 6 users logging in via IDM 
identities at the moment so it was not disruptive to make this sort of 
core change.



-Chris







Chris Dagdigian wrote:

Hi folks,

I've posted here and gotten amazing help on our odd setup with IPA 
having a 1-way trust to a massive remote AD forest with 90+ domain 
controllers and lots of child domains.


I'm running into a strange issue where I can resolve and manage users 
in child domain (NAFTA.COMPANY.ORG) but I am getting failures and just 
discovered an interesting error that relates to resolving a user in 
the EAME.COMPANY.ORG forrest.


However I've also been dragged down the rabbit hole tracking down 
errors that turned out to be meaningless so I figured my 1st question 
will be "is this the error should I be focusing on?"


This is my situation:

1. "id u...@nafta.company.org" works perfectly fine - no issues at all 
with RBAC, sudo and hosting SSH keys etc.


2. "id u...@eame.company.org" fails with "no such user"

3. We did not configure any specific SID-UID mapping rules in 
sssd.conf as we had assumed we'd use the "default" behavior



After digging through the logs I found this which seems VERY clear 
about the root cause:


(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] 
[dp_get_account_info_handler] (0x0200): Got request for 
[0x1][BE_REQ_USER][1][name=u474...@eame.company.org]
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] 
[sdap_idmap_sid_to_unix] (0x0040): Object SID 
[S-1-5-21-299502267-823518204-725345543-201173] has a RID that is 
larger than the ldap_idmap_range_size. See the "ID MAPPING” section of 
sssd-ad(5) for an explanation of how to resolve this issue.
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] 
[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID 
[S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user] 
(0x0020): Failed to save user [u474...@eame.company.org]
(Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users] 
(0x0040): Failed to store user 0. Ignoring.



The error about "Object SID has a RID that is larger than 
ldap_idmap_range_size .." seems pretty clear. I don't think this is a 
'rabbit hole' message - this seems like a real config problem on my end.


The problem is that I'm not quite sure what I should configure to 
resolve this. The man page for sssd-ad covers the topic but does not 
cover recommended configuration options.



Questions for this list:

1) Confirm that the "SID has an RID that is larger ..." error is real 
and worth chasing down ?


2) My understanding was that by default SSSD will hash SIDs and come 
up with unique UID and GID ranges that will be consistent across any 
machine bound to the same IDM mechanism. So I've not configured 
anything specific related to SID-to-UID mapping as we wanted to go 
with the default behavior used by SSSD. Obviously the default is not 
working and I've got to make a change. I just don't know what the 
recommended change should be. Help appreciated!




Config file details are below.


Regards,
Chris





This is the sssd/sssd.conf file on the IPA server:

###--

[domain/companyidm.org]
ldap_user_principal = nosuchattr
subdomain_inherit = ldap_user_principal
debug_level = 5
krb5_validate = True
cache_creden

[Freeipa-users] Any good CLI methods for testing connectivity from IPA replica to remote AD servers?

[Chris Dagdigian]

Hi folks,

I may have network blocks between one of my IPA replicas and the *many* 
remote AD servers that need to be queried but I can only see evidence of 
this in the authentication failures and the debug level logging.


Not sure how to test from the command line to verify connectivity or 
narrow down which ports may be getting blocked.


Are there any common CLI techniques, ldaps:// search queries or other 
commands that could be run from an IPA replica to confirm basic 
communication with a remote AD controller?


Thanks!

Chris

--
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] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Chris Dagdigian]

Really appreciate the high-level of insight and support on this list. 
Very refreshing!



Alexander Bokovoy wrote:

Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on
the replica?


krb5_child.log is totally empty (strange) as I thought I had debug_level 
= 10 set everywhere


ldap_child.log is posted at this URL due to length: 
http://chrisdag.me/ldap_child.log.sanitized.txt



There seem to be something weird with networking stack, because at
15:43:13 the next attempt to connect gets 'connection refused'. May be
389-ds is just warming up and there is not enough CPU or I/O to handle
the load? 





So, sssd on the replica is able to retrieve information from the
replica's LDAP server. It also is able to retrieve the trust topology
information and retrieve the trusted domain objects to use against the
forest root domains your deployment trusts.

But at the point when it tries to contact global catalog and domain
controllers from the trusted domains, it cannot access them, so it
considers them offline.

Can you show us your /etc/krb5.conf on this replica, content of files in
/var/lib/sss/pubconf/krb5.include.d subdirectory which get included into
/etc/krb5.conf, and the logs I asked above?


Here is sanitized krb5.conf from the replica. The CAPATH information was 
provided by someone
on this list to resolve a problem with the CAPATHs being wrong by 
default on v4.2 with
our complex AD environment. We've since made an Ansible playbook to 
update the krb5.conf file

on our client machines.

We comment out the include path again based on our v4.2 issues howeve

includedir /etc/krb5.conf.d/

## Disabled due to SSSD Bug related to CA paths
## across different AD trusts
# includedir /var/lib/sss/pubconf/krb5.include.d/

## This is the manual COMPANY fix:

[capaths]
COMPANYAWS.ORG = {
  COMPANYIDM.ORG = COMPANYAWS.ORG
}
COMPANYIDM.ORG = {
  COMPANYAWS.ORG = COMPANYAWS.ORG
  COMPANY.ORG = COMPANY.ORG
  EAME.COMPANY.ORG = COMPANY.ORG
  APAC.COMPANY.ORG = COMPANY.ORG
  LATAM.COMPANY.ORG = COMPANY.ORG
  NAFTA.COMPANY.ORG = COMPANY.ORG
}
COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = COMPANYIDM.ORG
 dns_lookup_realm = true
 dns_lookup_kdc = true
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}
 canonicalize = true

[realms]
 COMPANYIDM.ORG = {
  kdc = usaeilidmp002.COMPANYidm.org:88
  master_kdc = usaeilidmp002.COMPANYidm.org:88
  admin_server = usaeilidmp002.COMPANYidm.org:749
  default_domain = COMPANYidm.org
  pkinit_anchors = FILE:/etc/ipa/ca.crt
}

[domain_realm]
 .COMPANYidm.org = COMPANYIDM.ORG
 COMPANYidm.org = COMPANYIDM.ORG
 usaeilidmp002.COMPANYidm.org = COMPANYIDM.ORG

[dbmodules]
  COMPANYIDM.ORG = {
db_library = ipadb.so
  }

## Also from the include path we had previously commented out
[plugins]
 localauth = {
  module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
 }







Can you make sure that the replica is actually able to reach AD DCs for
the trusted domains (ports tcp/3268, tcp/389, tcp/88, udp/88, udp/53 at
least)? 


I'm going to see if I can come up with a new verification method. My 
normal way of "proving" connectivity
in this AWS environment is to use the VPC flow logs to search for REJECT 
alerts between the NIC on this
IPA server and the remote AD domain controller. This was very effective 
in proving on our master IPA

that something was blocking UDP:88 to a few remote controllers.

Sadly I can't find any REJECT messages for this replica server so I've 
been assuming connectivity was

totally fine. Will try to test via other methods.




--
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] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Chris Dagdigian]

Oddly enough the keytab location on the replica is sort of empty ...

 ls -al /var/lib/sss/keytabs/

total 4
drwx--. 2 sssd sssd  32 Dec 23 13:58 .
drwxr-xr-x. 9 root root  94 Dec 19 17:05 ..
-rw---  1 sssd sssd 219 Dec 20 20:40 company.org.keytab



Jakub Hrozek wrote:

In addition, can you also see if the keytab with the trust principal is
there? Probably it would be /var/lib/sss/keytabs/shanetest.org.

At15:43:11,  sssd tried to fetch the keytab for this trust:
(ThuDec 22 15:43:11  2016) [sssd[be[companyidm.org]]] 
[ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for 
shanetest.org
(ThuDec 22 15:43:11  2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_send] 
(0x0400): Retrieving keytab forcompanyidm$@SHANETEST.ORG  from 
usaeilidmp002.companyidm.org into 
/var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache 
/var/lib/sss/db/ccache_companyidm.ORG

But fails:
SASL Bind failed Can't contact LDAP server (-1) !
Failed to bind to server!
Failed to get keytab
(ThuDec 22 15:43:11  2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_done] 
(0x0040): ipa-getkeytab failed with status [2304]
(ThuDec 22 15:43:11  2016) [sssd[be[companyidm.org]]] [ipa_getkeytab_recv] 
(0x2000): ipa-getkeytab status 2304
(ThuDec 22 15:43:11  2016) [sssd[be[companyidm.org]]] 
[ipa_server_trust_1way_kt_done] (0x0080): ipa_getkeytab_recv failed: 1432158265

What I don't see in the logs, though is that if we try and re-fetch the
keytab after going online (we should, though).


--
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] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Chris Dagdigian]

Hi folks,

Summary:  Replica w/ Trust agents can't resolve AD users. Not sure which 
debug_level=log error I should focus on. Would appreciate extra eyeballs 
on this ..


Have a brand new replica (v4.4) running and after installing the AD 
trust agents I still can't recognize users who exist in the trusted AD 
domains.


Running at debug_level=10 for logging as usual however deleting the logs 
and doing a fresh reboot followed by trying to resolve a users still 
make 4000+ log entries so rather than include it here I've posted a 
sanitized sssd_domain.log file here:


http://chrisdag.me/sssd_companyidm.org.log.txt

There are two sets of messages in that massive log file that concern me 
but I don't know enough yet to figure out which one to focus on.


The first set of messages show what appears to be a fatal error in 
connecting to the local ldap:// server on the replica.


However -
 - dirsirv logs look fine
 - the various ldapsearch commands in the Free-IPA troublehooting page 
work to query both the replica and the remote master

 - 'ipactl status' shows directory services running
 - no firewall blocking and AWS VPC flowLogs show no REJECT traffic 
whatsoever for the NIC on the replica


But I still see this scary section in the logs right after startup:

This is about line #577 in the log where I see some scary LDAP related 
errors:
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [shanetest.org] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [companyaws.org] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [child2.shanetest.org] as subdomain of 
[companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [EAME.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [APAC.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [LATAM.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [new_subdomain] 
(0x0400): Creating [NAFTA.COMPANY.ORG] as subdomain of [companyidm.org]!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [companyidm.org] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [shanetest.org] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [shanetest.org] is a forest root of 
[child2.shanetest.org]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [companyaws.org] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[EAME.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[APAC.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[LATAM.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[link_forest_roots] (0x2000): [COMPANY.ORG] is a forest root of 
[NAFTA.COMPANY.ORG]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[sss_write_domain_mappings] (0x0200): Mapping file for domain 
[companyidm.org] is 
[/var/lib/sss/pubconf/krb5.include.d/domain_realm_companyidm_org]
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [become_user] 
(0x0200): Trying to become user [0][0].
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [become_user] 
(0x0200): Already user [0].
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] [main] (0x0400): 
Backend provider (companyidm.org) started!
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[ipa_server_trusted_dom_setup_send] (0x1000): Trust direction of 
subdom shanetest.org from forest shanetest.org is: one-way inbound: 
local domain trusts the remote domain
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[ipa_server_trusted_dom_setup_1way] (0x0400): Will re-fetch keytab for 
shanetest.org
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[ipa_getkeytab_send] (0x0400): Retrieving keytab for 
companyidm$@SHANETEST.ORG from usaeilidmp002.companyidm.org into 
/var/lib/sss/keytabs/shanetest.org.keytabRw7Iai using ccache 
/var/lib/sss/db/ccache_companyidm.ORG
(Thu Dec 22 15:43:11 2016) [sssd[be[companyidm.org]]] 
[child_handler_setup] (0x2000): Setting up signal handler up for pid [649]
(Thu Dec 22 15:43:11 

[Freeipa-users] really dumb question - is an IPA replica automatically a client as well?

[Chris Dagdigian]

Working on a messy multi-AD / multi-child-domain environment ...

Just deployed my 1st replica server after the v4.4 upgrade

The IPA replica seems fine and "ipactl status" reports no issues. The 
webUI clearly shows all of the values/config that came over from the master


However the replica server does not resolve or enumerate any users in 
any of the trusted AD domains despite sssd.conf and krb5.com being 
similar to the IPA master. No obvious errors or blocked traffic although 
I have not yet enabled debug=10 logging yet.


Before I begin the standard krb5 and sssd troubleshooting I wanted to 
ask the dumb question  first -- does an IPA replica automatically get 
enrolled as a managed client? Should I expect it to recognize the remote 
AD user IDs by default?


Chris

--
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] Confirming no extra/special ports need to be opened for replication traffic?

[Chris Dagdigian]

Much appreciated, thank you!

Martin Babinsky wrote:
IIRC in IPA v3.0 there was 7389 port used for CA replication, but in 
more recent versions this is not required anymore.


--
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] Confirming no extra/special ports need to be opened for replication traffic?

[Chris Dagdigian]

Been reading various generations of documentation to find out if I need 
additional TCP or UDP ports opened for IPA replication between 
VPN-connected dataceners.


I think the modern answer is no? We just need the standard IPA ports 
open between all of the IPA master/replicas that chat to each other?


TCP Ports:
  * 80, 443: HTTP/HTTPS
  * 389, 636: LDAP/LDAPS
  * 88, 464: kerberos
  * 53: bind
UDP Ports:
  * 88, 464: kerberos
  * 53: bind
  * 123: ntp


-Chris


--
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Massive thank you; will test ASAP.

We mainly have to support CentOS/RHEL-6 and CentOS/RHEL-7 clients. Is 
there any established guidance on upgrading SSSD in these environments? 
Some sort of trusted repo where RPMs are built? I can hit the wiki and 
website but figured I'd ask as well. Not sure what other dependencies 
the SSSD framework may have or pull in.


Sumit Bose wrote:

}

at the very beginning of /etc/krb5.conf before and include or includedir
directives should fix it. With the broken configuration libkrb5 thinks
that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG
which is not the case, everything has to go via COMPANY.ORG because
that's the domain which trusts COMPANYIDM.ORG.

Updating SSSD to a version with the fix might help as well.

HTH


--
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Sumit Bose wrote:

>  Am I being stupid (again?)  Obviously the krb5_validate=false setting needs
>  to be fixed. Just not sure if I should work on a fix within 4.2 or move to
>  4.4 and see if it gets resolved as part of other changes.


The validation issue might have different reasons. One might be
https://fedorahosted.org/sssd/ticket/3103  where SSSD creates a wrong
Kerberos configuration snippet. Fixes are available for sssd-1.13 and
later. But there might be other reasons as well.

If you don't mind please send the krb5_child.log with debug_level=10
covering an authentication attempt with 'krb5_validate = true' and the
content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain.


Thanks Sumit,

Info you requested is attached. These logs are from a client machine. I 
confirmed that I could not authenticate with krb5_validate = True and 
that I could authenticate when I switched krb5_validate=false.  I set 
the value to "True", turned up debug logging to 10 and then stopped SSSD 
service after my 3 login tries to try to constrain the log volume.


Still ended up with 1200+ lines in krb5_child.log though

Here is the info you requested (sanitized)

URL to krb5_child.log since it is pretty lengthy:
-
http://chrisdag.me/krb5_child.log.txt


And we actually had 2 domain_realm* files which is I think due to our 
difference in DNS for client hostnames vs DNS for the IPA server:
Our CAPATH info does look like that SSSD issue you mentioned (ticket 
3103)  ...



This is domain_realm_companyaws_org:
--
[domain_realm]
.COMPANY.ORG = COMPANY.ORG
COMPANY.ORG = COMPANY.ORG
.EAME.COMPANY.ORG = EAME.COMPANY.ORG
EAME.COMPANY.ORG = EAME.COMPANY.ORG
.APAC.COMPANY.ORG = APAC.COMPANY.ORG
APAC.COMPANY.ORG = APAC.COMPANY.ORG
.LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
.NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
[capaths]
COMPANY.ORG = {
  COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
  COMPANY.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
  COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
  EAME.COMPANY.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
  COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
  APAC.COMPANY.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
  COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
  LATAM.COMPANY.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
  COMPANYAWS.ORG = COMPANY.ORG
}
COMPANYAWS.ORG = {
  NAFTA.COMPANY.ORG = COMPANY.ORG
}




And this is domain_realm_companyidm_org:

[domain_realm]
.COMPANY.ORG = COMPANY.ORG
COMPANY.ORG = COMPANY.ORG
.EAME.COMPANY.ORG = EAME.COMPANY.ORG
EAME.COMPANY.ORG = EAME.COMPANY.ORG
.APAC.COMPANY.ORG = APAC.COMPANY.ORG
APAC.COMPANY.ORG = APAC.COMPANY.ORG
.LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
.NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
[capaths]
COMPANYAWS.ORG = {
  COMPANYIDM.ORG = COMPANYAWS.ORG
}
COMPANYIDM.ORG = {
  COMPANYAWS.ORG = COMPANYAWS.ORG
}
COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
  COMPANY.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
  EAME.COMPANY.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
  APAC.COMPANY.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
  LATAM.COMPANY.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
COMPANYIDM.ORG = {
  NAFTA.COMPANY.ORG = COMPANY.ORG
}





--
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Our problem is largely solved but we are using some "do not use in 
production!" settings so I wanted to both recap our solution and ask 
some follow up questions.


Our setup:
-
 - FreeIPA 4.2 running on CentOS-7 in AWS VPC
 - Edge-case split DNS setup. Our cloud clients are "company-aws.org" 
while IPA is "company-ipa.org" realm/domain
 - Massive need to authenticate against AD Forest COMPANY.COM which 
includes a ton of child domains (NAFTA.COMPANY.COM, etc.)


Problem
---
- AD users are recognized and can be enumerated as long as I use 
usern...@nafta.company.com

- "su - " works as root to become the AD user
- All methods that require password check (SSH login mainly) failed

The breakthrough was the advice from Sumit to add the 
ldap_user_principal and subdomain_inherit settings. The core problem on 
our end seemed to be issues with having the AD user UPN get sorted out. 
Something was failing when u...@nafta.company.com was shortened to 
u...@company.com and we saw the recurring error about " ... UPN is quite 
different ... "  in the sssd domain logs.



Solution (Server Side)
-
In /etc/sssd/sssd.conf:
 ldap_user_principal = nosuchattr
 subdomain_inherit = ldap_user_principal
 krb5_validate = false


Solution (IPA client side)

In /etc/sssd/sssd.conf:
 krb5_validate = false


I think the main problem is obvious. Even Sumit was clear to state that 
"krb5_validate = false" should be used for testing only.


However if we remove that setting password checking breaks.


So the basic "what next question" for the experts is:


1. Do we chase down whatever config error we have that requires 
krb5_validate=false ?
2. Or do we assume that that problem is related to the UPN problem and 
related AD-across-child-domains that appear to be resolved in IPA-4.4? I 
keep getting the sense that massive AD-related things have been improved 
recently in 4.3 and 4.4


My gut feeling is that it is our odd UPN issue that is breaking things 
so rather than bend over backwards to try to figure out why 
krb5_validate=false on our IPA-4.2 setup I'm sort of leaning towards 
trying to go for an upgrade to IPA-4.4 and hope that whatever issue 
forced us to disable krb5_validate is resolved in the new updates.


Am I being stupid (again?)  Obviously the krb5_validate=false setting 
needs to be fixed. Just not sure if I should work on a fix within 4.2 or 
move to 4.4 and see if it gets resolved as part of other changes.



Regards,
Chris






--
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Confirmed that adding the following to /etc/sssd/ssd.conf on the SERVER 
fixed SSH password checks on the server itself!


ldap_user_principal = nosuchattr
subdomain_inherit = ldap_user_principal

The core problem does appear to be the "... UPN is quite different" 
error when we try to login as u...@nafta.company.org which then gets 
shortened to u...@company.org. It's hard to read the volume of 
debug_level 10 logs but it's clear that it's getting hung up with 
principals when talking to the remote AD servers.


I can now login to the IPA server with my standard AD credentials which 
has been impossible until just now.


However no luck on IPA clients. Can you confirm that the above sssd.conf 
workaround is for the IPA server only as the thread you linked to 
indicates or is this a change I should push down to clients? I'm going 
to build some fresh clients just in case.


And knowing that this workaround seems to be getting close to totally 
resolving our issue would you recommend IPA-4.4 for our environment 
where we have lots of AD trusts in play combined with DNS-DOMAIN 
differences between the IPA realm and the managed clients? Or is it 
better to stick with the workaround settings + the IPA-4.2 release that 
comes with CentOS/RHEL-7?


Thanks!

Chris


Sumit Bose wrote:

Both authentications where successful against the backend. For the logs
it looks like you use an alternative domain suffix on the AD side so
that all user if other domains in the forest can use the forest root
suffix as realm, in the user principal (u...@nafta.company.org  ->
u...@company.org).

I would expect that there are messages like "UPN used in the request
...differ by more than just the case." in the domain log at 'TueDec  6
19:57:11'  and 'TueDec  6 19:57:14'.

If that's the case updating to4.4  would help because in this release
IPA can forward the enterprise principals properly and SSSD will not
reject the changed principal because sSSD will be aware of the change.

But there are workarounds to make it work with your version as well,
please see e.g. the suggestion from
https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html  .


--
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Chris Dagdigian]

Sumit,

Thank you so much for your assistance and eyeballs on the massive 
logset. I've repeatedly found the level of support on this list to be 
fantastic. Some day I'll have enough hands-on experience to repay in 
kind ...


We do actually use a different domain for the clients:

Our clients are "company-aws.org" while being managed by 
"company-idm.org" and talking to AD forests and many child domains in 
"company.org".


It's a fairly hairy setup driven mostly by "above my pay grade" distrust 
of IaaS cloud environments like AWS VPCs combined with existing use of 
Kerberos that we don't want to break. Hence putting IDM/IPA in a 
separate domain and realm altogether.


I actually DID see the "UPN used in the request .. differ" error 
messages all over the place.


I will try the workaround linked to below and report back.

Follow-up on the 4.4 release:

For people using CentOS/RHEL 7.x is it recommended to use  IPA 4.4 code 
in production? Our needs are pretty simple once you get beyond the 
complex AD environment - we just need simple SSH password authentication 
and a bit of RBAC feature for a small to midsize cloud footprint.  I'm 
guessing that running 4.4 if we have passwords working would not be all 
that risky for us. It really does seem like a large amount of recent IPA 
development has focused on AD integration so I'm actually fairly 
interested and motivated to step up from our 4.2 version.


Regards,
Chris


Sumit Bose wrote:


Both authentications where successful against the backend. For the logs
it looks like you use an alternative domain suffix on the AD side so
that all user if other domains in the forest can use the forest root
suffix as realm, in the user principal (u...@nafta.company.org  ->
u...@company.org).

I would expect that there are messages like "UPN used in the request
...differ by more than just the case." in the domain log at 'TueDec  6
19:57:11'  and 'TueDec  6 19:57:14'.

If that's the case updating to4.4  would help because in this release
IPA can forward the enterprise principals properly and SSSD will not
reject the changed principal because sSSD will be aware of the change.

But there are workarounds to make it work with your version as well,
please see e.g. the suggestion from
https://www.redhat.com/archives/freeipa-users/2016-May/msg00205.html  .

HTH

bye,
Sumit


--
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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

100% correct. We are OK with losing GSSAPI authentication if we can 
operate in a different DNS domain than
the IPA server that "glues" together all of our various Active Directory 
trusts. We want password authentication
from Active Directory as our main concern with role-based access control 
coming in as a strong second desire.


The Redhat/IPA documentation and links that Alexander posted below on 
this are quite good and the issues on our end have generally come
from following more generic deployment instructions that don't cover the 
different-DNS-domain situation.


The quality of technical insight on this list has been fantastic. If our 
"different DNS" setup is of interest to
others I'd be happy to write up our architecture and configurations in 
more detail once this project settles
down. At the very least I should be able to prepare a concise "lessons 
learned" summary that details the
configuration settings that deviate from the norms advised in the more 
general-purpose instructions.


Regards,
Chris

Alexander Bokovoy wrote:

Apologies I must have been unclear. What I was trying to say is that
we are going for the "hosts in the different DNS domain" deployment 
scenario ...


- We have unique domain name and realm for IPA:  company-ipa.org
- We use company-aws.org in AWS and have  our own Active Directory 
servers for: company-aws.org
- We want to use ipa-client to bind our servers to company-ipa.org 
but use DNS names from company-aws.org for operation


Our end goal:
- We have many external AD forests we are linking to company-ipa.org 
one at a time
- End goal: operate hosts with DNS name "company-aws.org" as IPA 
clients of "company-ipa.org" using AD logins coming from the external 
trusts

This setup should work with password-based authentication. It will not
work with GSSAPI (Kerberos) authentication. I think this is what you are
aware of and accepted as the limitation.

For the benefit of others, here is the list of articles and
documentation of the topic of mixed DNS domains/hostnames with Active
Directory:

- High-level description:
http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/

- Documentation chapter:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#ipa-in-ad-dns 



- Technical details:
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain

There is nothing we can do with the Active Directory limitations beyond
these documents.



--
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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

Sumit Bose wrote:

NO. It is the other way round.

It is_not_  recommended and will not even work properly to use the same
DNS domain for IPA and AD. Even worse with using the same realm for
both, this cannot work at all.

It is required to have a different realm name for the IPA domain and it
is important to use a different DNS domain as well (a bit is possible
with hosts in the same DNS domain but you loose functionality here).

Where did you find the recommendation to user the same DNS domain and
realm?



Apologies I must have been unclear. What I was trying to say is that
we are going for the "hosts in the different DNS domain" deployment 
scenario ...


- We have unique domain name and realm for IPA:  company-ipa.org
- We use company-aws.org in AWS and have  our own Active Directory 
servers for: company-aws.org
- We want to use ipa-client to bind our servers to company-ipa.org but 
use DNS names from company-aws.org for operation


Our end goal:
- We have many external AD forests we are linking to company-ipa.org one 
at a time
- End goal: operate hosts with DNS name "company-aws.org" as IPA clients 
of "company-ipa.org" using AD logins coming from the external trusts


-Chris




--
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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

< huge log sample deleted >

Sumit Bose wrote:
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [validate_tgt] 
(0x0020): TGT failed verification using key for 
[host/usaeilvdip001.company-aws@company-idm.org].


ok, it is the ticket validation which fails. You can get around this for
testing by setting 'krb5_validate = false' in the [domain/...] section
of sssd.conf. But please use this only for testing because this error
indicates that there are issues in your setup/configuration.


Much appreciated. Will test today.

But your host principal
host/usaeilvdip001.company-aws@company-idm.org looks odd as well.
Why is the host in the AD DNS domain, this calls for trouble.
Additionally I wonder why the realm part '@company-idm.org' was created
in lower-case while joining the IPA this should be created upper-case.
Or is this all due to sanitation?


{ Capitalization problem was a sanitation error }

At the time we set up the IPA environment the only AD domain we had 
administrative control over
was already in use and could not easily be reconfigured to meet the best 
practices for having an

IPA server sit in the same domain name and realm

After reading the documentation and a lot of posts on redhat.com we 
decided that the IPA server
would have to be in a completely new autonomous domain name, DNS zone 
and Kerberos realm. The
IPA instructions (and ipa-client-install options) all seem to indicate 
that although not a best practice it
is something that was supported although there is a loss of 
functionality to be expected.


So we run servers as FQDN members of company-aws.org but they are IPA 
clients of company-ipa.org


My understanding is that if we:

 1. Bind a Linux IPA client to company-ipa.com
 2. But configure the Linux client to have a hostname of 
client.company-aws.com


.. then what we primarily lose is kerberos related service functionality 
for logged-in users


Since our core need was for AD password authentication and RBAC control 
over Linux hosts we

decided to move forward with this odd config.

Would be greatly interested if I'm way off base on use of totally 
autonomous IPA realms and domain names.



(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [get_and_save_tgt]
(0x0020): 1242: [-1765328377][Server not found in Kerberos database]
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [map_krb5_error]
(0x0020): 1303: [-1765328377][Server not found in Kerberos database]
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [k5c_send_data]
(0x0200): Received error code 1432158209
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [pack_response_packet]
(0x2000): response packet size: [20]
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [k5c_send_data]
(0x4000): Response sent.
(Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [main] (0x0400):
krb5_child completed successfully
[root@usaeilvdip001 sssd]#




The logs indicate that the user actually come from the member domain in
the forest: usern...@nafta.company.org. But the [capath] section you
added to krb5.conf only contains the forest root.


COMPANY-AWS.ORG = {

   COMPANY-IDM.ORG = COMPANY-AWS.ORG

}

COMPANY-IDM.ORG = {

   COMPANY-AWS.ORG = COMPANY-AWS.ORG

}



Please try to add the member domain as well. The result might look like
this: (assuming COMPANY-AWS is the forest root, NAFTA is the member
domain and COMPANY-IDM is the IPA domain)

COMPANY-AWS.ORG = {

   COMPANY-IDM.ORG = COMPANY-AWS.ORG

}

COMPANY-IDM.ORG = {

   COMPANY-AWS.ORG = COMPANY-AWS.ORG
   NAFTA.COMPANY.ORG = COMPANY-AWS.ORG
}

NAFTA.COMPANY.ORG = {
   COMPANY-IDM.ORG = COMPANY-AWS.ORG
}


Thank you. I don't think our Linux client picked up the CAPATH changes 
needed
but I think the IPA server did the proper thing deep down in that 
include directory that

is referenced at the top of sssd.com.

Will check and verify.



You can test the configuration independent of SSSD by calling

kdestroy -A
kinit usern...@nafta.company.org
kvno host/usaeilvdip001.company-aws@company-idm.org

If kvno returns an error please rerun as

KRB5_TRACE=/dev/stdout kvno host/usaeilvdip001.company-aws@company-idm.org

and send the output.


Again, thanks for the time, attention and helpful replies.



HTH

bye,
Sumit


--
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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

Simpson Lachlan wrote:

By no means am I an expert, but isn't there meant to be a stanza in [realm] 
that looks like this?

auth_to_local = RULE:[1:$1@$0](^.*@DOMAIN.COM$)s/@DOMAIN.COM/@domain.com/
auth_to_local = DEFAULT



Appreciate the reply!

From what I can tell that stanza is not needed when there is a 
localauth provider for IPA (RHEL-7/Centos-7 basically) - I think the 
docs I read mentioned that the actions in the stanza are automatic or 
implicit when localauth plugin is present.


Both my IPA box and test client are CentOS-7 at the moment so I did not 
do the extra auth_to_local rule


Regards,
Chris

--
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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

Sumit Bose wrote:

Please send the full krb5_child.log with debug_level=10 in the
[domain/...] section of sssd.conf. My current guess is the ticket
validation fails. Which version of SSSD are you using?

bye,
Sumit



This is a CentOS 7 client running SSSD-1.13

Thank you. Lots of interesting info in this log. I've sanitized 
hostnames, username and IP but that was it:


### log data below 


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [main] (0x0400): 
krb5_child started.
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [unpack_buffer] 
(0x1000): total buffer size: [52]
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [unpack_buffer] 
(0x0100): cmd [249] uid [1843770609] gid [1843770609] validate [true] 
enterprise principal [false] offline [false] UPN [usern...@company.org]
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [k5c_setup_fast] 
(0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to 
[host/usaeilvdip001.company-aws@company-idm.org]
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[find_principal_in_keytab] (0x4000): Trying to find principal 
host/usaeilvdip001.company-aws@company-idm.org in keytab.
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [match_principal] 
(0x1000): Principal matched to the sample 
(host/usaeilvdip001.company-aws@company-idm.org).
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[check_fast_ccache] (0x0200): FAST TGT is still valid.
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [become_user] 
(0x0200): Trying to become user [1843770609][1843770609].
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [main] (0x2000): 
Running as [1843770609][1843770609].
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [k5c_setup] 
(0x2000): Running as [1843770609][1843770609].
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[set_lifetime_options] (0x0100): Cannot read 
[SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from 
environment.
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true]
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [main] (0x0400): 
Will perform pre-auth
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [tgt_req_child] 
(0x1000): Attempting to get a TGT
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 [get_and_save_tgt] 
(0x0400): Attempting kinit for realm [COMPANY.ORG]
(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455849: Getting 
initial credentials for usern...@company.org


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455913: FAST armor 
ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455943: Retrieving 
host/usaeilvdip001.company-aws@company-idm.org -> 
krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG@X-CACHECONF: 
from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result: 
-1765328243/Matching credential not found


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.455988: Sending 
request (169 bytes) to COMPANY.ORG


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.456104: Resolving 
hostname COMPANY.ORG


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.457461: Initiating 
TCP connection to stream 192.141.1.62:88


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.544892: Sending 
TCP request to stream 192.141.1.62:88


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.632904: Received 
answer (118 bytes) from stream 192.141.1.62:88


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.632941: 
Terminating TCP connection to stream 192.141.1.62:88


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633006: Response 
was from master KDC


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633037: Received 
error from KDC: -1765328316/Realm not local to KDC


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633070: Following 
referral to realm NAFTA.COMPANY.ORG


(Tue Nov 22 16:02:43 2016) [[sssd[krb5_child[4366 
[sss_child_krb5_trace_cb] (0x4000): [4366] 1479830563.633087: FAST armor 
ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org


(Tue Nov 22 16:02:43 2016) 

Re: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

Following up my own email after realizing my sssd debug info was better 
when I ran it via "# sssd -i -d 5" ...


Here are the relevant entries from sssd during a failed login attempt 
via SSH using AD credentials from usern...@nafta.company.com


-Chris


(Tue Nov 22 15:43:27 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): 
Received client version [0].


(Tue Nov 22 15:43:27 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): 
Offered version [0].


(Tue Nov 22 15:43:27 2016) [sssd[ssh]] [sss_parse_name_for_domains] 
(0x0200): name 't859...@nafta.company.org 
' matched expression for domain 
'NAFTA.COMPANY.ORG', user is t859531


(Tue Nov 22 15:43:27 2016) [sssd[be[company-idm.org]]] 
[be_get_account_info] (0x0200): Got request for [0x1][1][name=t859531]


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[sysdb_update_members_ex] (0x0020): Could not add member 
[t859...@nafta.company.org ] to group 
[name=t859...@nafta.company.org 
,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. 
Skipping.


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[sysdb_update_members_ex] (0x0020): Could not add member 
[t859...@nafta.company.org ] to group 
[name=t859...@nafta.company.org 
,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. 
Skipping.


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success 
(Success)


(Tue Nov 22 15:43:28 2016) [sssd[ssh]] [client_recv] (0x0200): Client 
disconnected!


(Tue Nov 22 15:43:28 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): 
Received client version [0].


(Tue Nov 22 15:43:28 2016) [sssd[ssh]] [sss_cmd_get_version] (0x0200): 
Offered version [0].


(Tue Nov 22 15:43:28 2016) [sssd[ssh]] [sss_parse_name_for_domains] 
(0x0200): name 't859...@nafta.company.org 
' matched expression for domain 
'NAFTA.COMPANY.ORG', user is t859531


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[be_get_account_info] (0x0200): Got request for [0x1][1][name=t859531]


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]


(Tue Nov 22 15:43:28 2016) [sssd[be[company-idm.org]]] 
[sysdb_update_members_ex] (0x0020): Could not add member 
[t859...@nafta.company.org ] to group 
[name=t859...@nafta.company.org 
,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. 
Skipping.


(Tue Nov 22 15:43:29 2016) [sssd[be[company-idm.org]]] 
[sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such 
object](32)[ldb_wait: No such object (32)]


(Tue Nov 22 15:43:29 2016) [sssd[be[company-idm.org]]] 
[sysdb_update_members_ex] (0x0020): Could not add member 
[t859...@nafta.company.org ] to group 
[name=t859...@nafta.company.org 
,cn=groups,cn=NAFTA.COMPANY.ORG,cn=sysdb]. 
Skipping.


(Tue Nov 22 15:43:29 2016) [sssd[be[company-idm.org]]] 
[acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success 
(Success)


(Tue Nov 22 15:43:29 2016) [sssd[ssh]] [client_recv] (0x0200): Client 
disconnected!


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
Received client version [3].


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
Offered version [3].


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_cmd_preauth] (0x0100): 
entering pam_cmd_preauth


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [sss_parse_name_for_domains] 
(0x0200): name 't859...@nafta.company.org 
' matched expression for domain 
'NAFTA.COMPANY.ORG', user is t859531


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): 
command: SSS_PAM_PREAUTH


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): 
domain: NAFTA.COMPANY.ORG


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): user: 
t859531


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): 
service: sshd


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh

(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
not set


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): rhost: 
usrelnu4239n3y2.NAFTA.COMPANY.ORG


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): 
authtok type: 0


(Tue Nov 22 15:43:32 2016) [sssd[pam]] [pam_print_data] (0x0100): 

[Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Chris Dagdigian]

Upfront
 - I know this question is fairly common and I do read the list and 
archives, honest!
 - I'm following the SSSD troubleshooting wiki and running with debug 
settings for PAM and SSH

 - Still not quite sure where my config problem lies

 - I see "Server not found in kerberos database" in /var/log/messages 
so I think I have a simple /etc/krb5.conf error; possibly a very simple 
root cause like my client can't use DNS to autodiscover a KDC. Not 100% 
sure how to confirm that



Setup:

 - We run an IPA server at COMPANY-IDM.ORG with the goal of using it as 
"glue" for multiple Active Directory relationships
 - Successful trusts made with a number of test AD forest and domains, 
including SSH logins all working fine

 - Got the Trust set up to the real COMPANY.ORG forest last night
 - Trust to COMPANY.ORG went in just fine
 - We can fetch trusted domains through COMPANY.ORG and see all the 
children we expect to see (excellent!)


Situation:

 - I can resolve usern...@nafta.company.org on IPA server and bound client
 - I can "kinit usern...@nafta.company.org" on the IPA server and ipa 
managed client
 - From root I can "sudo usern...@nafta.company.org" on IPA and client 
server and end up as proper user in proper homedir
 - I can login via SSH to IPA server and client machines as 
u...@testdomain.org
 - ping COMPANY.ORG and NAFTA.COMPANY.ORG resolves to the remote AD 
servers so I think DNS forwarding is OK


BUT -- any sort of "ssh usern...@nafta.company.org" fails, client sees 
variations of "permission denied"; nothing super useful so far in 
security, ssh or sssd logs


So basically password checking is broken for the actual COMPANY.ORG 
trust we set up last night.


When I had this issue with our test AD domains I think the answer was 
that "client could not discover which KDC to contact for password 
checking" so our response was to customize the krb5.conf file to 
explicitly enable DNS lookups..


This feels to me like either I've messed up sssd.conf or perhaps more 
likely I'm missing a config setting in krb5.conf that is specific to 
password checking for COMPANY.ORG and NAFTA.COMPANY.org



We are running in AWS with VPC Flow Logs enabled and there are no 
obvious REJECT logs showing blockage of traffic to KDC or Domain Controllers



Seeking tips and any guidance people can provide!

Without burying people in log and config data, here is what I think the 
relevant info on our side is:


/etc/krb5.conf (IPA client)
-

[libdefaults]

  default_realm = COMPANY-IDM.ORG
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}

[realms]

  COMPANY-IDM.ORG = {
kdc = usaeilidmp001.company-idm.org:88
master_kdc = usaeilidmp001.company-idm.org:88
admin_server = usaeilidmp001.company-idm.org:749
default_domain = company-idm.org
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }

[domain_realm]

ipa-client.company-aws.org = COMPANY-IDM.ORG

[capaths]

COMPANY-AWS.ORG = {

  COMPANY-IDM.ORG = COMPANY-AWS.ORG

}

COMPANY-IDM.ORG = {

  COMPANY-AWS.ORG = COMPANY-AWS.ORG

}



Here is /etc/sssd/sssd.conf from an IPA client:
-

[domain/company-idm.org]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = company-idm.org
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname =  client.company-aws.org
chpass_provider = ipa
ipa_server = _srv_, usaeilidmp001.company-idm.org
dns_discovery_domain = company-idm.org

[sssd]

debug_level = 6
services = nss, sudo, pam, ssh
config_file_version = 2

domains = company-idm.org

[nss]

homedir_substring = /home

[pam]

debug_level = 10

[sudo]

[autofs]

[ssh]

debug_level = 6

[pac]

[ifp]



And finally after turning on debug here is some output from sssd_pam.log 
with debug mode set:

---

(Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_check_user_search] (0x0400): 
Returning info for user [usern...@nafta.company.org]
(Tue Nov 22 14:55:07 2016) [sssd[pam]] [pd_set_primary_name] (0x0400): 
User's primary name is usern...@nafta.company.org (Tue Nov 22 14:55:07 
2016) [sssd[pam]] [pam_initgr_cache_set] (0x2000): 
[usern...@nafta.company.org] added to PAM initgroup cache
(Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dp_send_req] (0x0100): 
Sending request with the following data:
(Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): 
command: PAM_OPEN_SESSION
(Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): 
domain: NAFTA.COMPANY.ORG (Tue Nov 22 14:55:07 2016) [sssd[pam]] 
[pam_print_data] (0x0100): user: usern...@nafta.company.org (Tue Nov 22 
14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): service: su-l
(Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_print_data] (0x0100): tty: 
pts/0
(Tue Nov 22 14:55:07 2016) [sssd[pam]] 

[Freeipa-users] anyone else getting porn spam pretending to be replies to freeipa-users threads?

[Chris Dagdigian]

Got a porn spam today that had a subject header of:


Re: [Freeipa-users] URL is changing on the browser


Have to admit that got through my spam filter and got me to open the email.

It's clear that it was not a list message; looks like something may be 
mining the public list archives to pull email addresses and plausible 
sounding subject lines.


Mildly interested if anyone else got an email like this?

-Chris


--
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] URL is changing on the browser

[Chris Dagdigian]

I'm still interested in this topic as our IPA servers are on private AWS 
subnets and it would be really nice to have an internal AWS ALB or ELB 
be the user-facing interface so we can route traffic between IPA systems 
and only "advertise" a single hostname for access. Plus it would be 
great to put the load balancer name into the various sssd.conf and 
krb5.conf client files since our internal DNS-based service discovery 
has some brittleness that is outside my control to fix.


I played with this for a short time and hit the "IPA redirects to it's 
internal FQDN" problem as well. Now that this appears to be a somewhat 
simple tweak to the httpd.conf type files I may start playing around 
with putting private IPA systems behind a private AWS load balancer


Chris



Deepak Dimri wrote:

we discussed the options internally and finally decided to host ipa within the 
private subnets - our security team wast too comfortable  to  expose ipa 
servers on to the public network.


--
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] guidance and strategies for supporting production use including dev/test IPA systems?

[Chris Dagdigian]

Thanks to support from folks on this list I have a 3-node multi-site 
replicating FreeIPA system supporting a number of 1-way trusts to 
various AD Forests. Testing has gone well and it's clear that this "POC" 
will soon transition to production.


Because of the importance of this system to our environment I'm trying 
to flesh out a proper strategy for testing upgrades and updates in a way 
that lets us keep our system highly available and online.


And seeing how rapidly this software is being developed w/ new features 
and how dependent we are on the most recent version (or how badly I want 
to try the version in RHEL-BETA-3) I think this is a system we will 
possibly be upgrading somewhat often ...


I understand that replicas can run newer versions of IPA/IDM than the 
master so that is one path by which we can carefully test updates and 
patches but I don't think that covers all the scenarios ...


Can anyone share strategies or war stories for how testing is done in 
support of production IPA/IDM environments? Especially when Trusts need 
to be set up with many external AD systems?


Do people run discrete standalone dev/test IPA domains/realms to create 
isolated  environments or is there some other good strategy that allows 
testing to be done within the same domain/realm?


Thanks!

-Chris

--
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] Novice question re IPA management of host RBAC login, sudo and ssh key management for users who are only in Active Directory

[Chris Dagdigian]

Perfect thank you. I tend to get too wordy in my emails. You've 
described exactly what I'm going for.


Follow up question - Will a similar approach work for users (not groups) 
as well if there is a small collection of AD-defined people I want to 
hold and distribute SSH public keys for?


Happy to document our setup or write up a HowTO or intro guide for other 
novices if we are trying something that is not often done.


Regards,
Chris


Baird, Josh wrote:

Hi,

If I'm understanding you correctly - you will want to nest 'external' groups 
into POSIX groups for assigning policy (HBAC, sudo, etc) to your AD users.  
There are examples of this in the IdM documentation, but the gist is:

* Create an 'external' group in IPA (eg, ipa-group-add external_admins 
--external)
* Add your AD group as a member to the external group (eg, ipa group-add-member 
external_admins --external 'AD\groupname)
* Create a standard POSIX group in IPA (eg, ipa group-add admins)
* Add the external group as a member to the POSIX group (eg, 
ipa-group-add-members admins --groups external_admins)

Now you can define policy (HBAC, sudo) based on the 'admins' POSIX group and 
the policies will apply to the AD users in the AD\groupname group.

Hope this helps.

Thanks,

Jos


--
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] Novice question re IPA management of host RBAC login, sudo and ssh key management for users who are only in Active Directory

[Chris Dagdigian]

Thanks to great tips and pointers from people on this list (h/t 
Alexander B) I was able to build an IPA master + replica setup that can 
recognize and allow logins from users coming from multiple disconnected 
AD Forests with 1-way trusts to the IPA servers


Sanitized view of our AWS footprint:

AD Servers & IPA:

AD Forest #1:   company-test.org
AD Forest #2:   company-aws.org
AD Forest #3:   company.org
IPA Domain/Realm:company-ipa.org   (successful 1-way trusts to 
company-test.org and company-aws.org etc.)


With basic recognition of users and working SSH logins based on AD 
username and passwords I'm moving on to trying to use the far more 
interesting IPA/IDM features.


Using user accounts defined locally on the IPA server I'm having a blast 
uploading SSH keys and creating sudo rules and groups. So the natural 
next question is "can we do this for users who exist only in remote AD 
controllers?


IPA is doing 100% of the UID/GID/Posix stuff management - we are only 
pulling usernames & groups from AD and checking passwords against the AD 
servers.


The basic question -- is it possible for me to get to "hybrid linux user 
management" nirvana whereby IPA/IDM manages everything about AD users 
except for their username and passwords?


Tried to find this in the official documentation but it dives instantly 
into deep topics about user data mapping, custom schemas and dealing 
with POSIX data served up by the AD controllers. Hard to figure out the 
boundary between what IPA can support with local user accounts vs  what 
it can do when the users exist in remote AD forests.


Any URLs or documentation pointers would be appreciated

Regards,
Chris




--
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] Debugging SSH password-based authentication when IPA client is in a different DNS domain

[Chris Dagdigian]

Alexander Bokovoy wrote:

you don't have explicit definition for the AD realms and you don't allow
Kerberos to discover neither realms nor their KDCs via DNS SRV records.

The latter happened because you have used --server option when
configuring the client -- man page for ipa-client-install has a section
explaining discovery and influence of options on it.

That's your problem. It also reveals that your reading of the wiki was
cursory, but that's another problem. :)



Huge thanks to Alexander Bokovoy for his patient guidance.

Following up to close out this thread with a solution that worked for 
our multi AD forest setup where client DNS name is different from 
IDM/IPA domain/realm


There were 2 changes needed to /etc/krb5.conf  to get password login via 
SSH working along with everything else ...


Change #1 was simplifying the [domain_realm] settings down to a very 
tightly scoped config that would allow additional things to be auto 
discovered via DNS


Change #2 was setting "dns_lookup_realm = true" and "dns_lookup_kdc = 
true" in [libdefaults]  -- this was the main thing I missed because the 
wiki page at 
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain 
displays example config with these values already set to true. These 
settings were actually false on my client's krb5.conf file due to the 
way I ran the ipa-client-install command. It was my mistake to not 
carefully compare the full file contents.


So wrapping it all up, this is the /etc/krb5.conf file that enabled 
password logins via SSH - the other change in the file below is I 
commented out the includedir file and put those settings into the 
/etc/krb5.conf file so I could have everything in one place for 
troubleshooting.



To recap our setup we have 2 AD Forests and an IDM/IPA server running on 
it's own domain name rather than subdomain


AD Servers & IPA:

AD Forest #1:   company-test.org
AD Forest #2:   company-aws.org
IPA Server:   company-ipa.org   (successful 1-way trusts to 
company-test.org and company-aws.org)


IPA Client:
Client test hostname:  client.company-aws.org



-Chris


-


#File modified by ipa-client-install
#includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
default_realm = COMPANY-IDM.ORG
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}

[realms]
COMPANY-IDM.ORG = {
kdc = usaeilidmp001.COMPANY-IDM.org:88
master_kdc = usaeilidmp001.COMPANY-IDM.org:88
admin_server = usaeilidmp001.COMPANY-IDM.org:749
default_domain = COMPANY-IDM.org
pkinit_anchors = FILE:/etc/ipa/ca.crt
}

[domain_realm]
client.company-aws.org = COMPANY-IDM.ORG

[capaths]
company-aws.org = {
  COMPANY-IDM.ORG = company-aws.org
}
COMPANY-IDM.ORG = {
  company-aws.org = company-aws.org
}
company-test.org = {
COMPANY-IDM.ORG = company-test.org
}
COMPANY-IDM.ORG = {
company-test.org = company-test.org
}

--
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] Debugging SSH password-based authentication when IPA client is in a different DNS domain

[Chris Dagdigian]

Alexander Bokovoy wrote:
As 
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain

explains, you need to have proper mapping of domains to realms and have
proper definitions for those realms.

We don't see your krb5.conf, so if it deviates from what the wiki
describes, you need to be explicit in your details. 
Much appreciated.  Here is the krb5.conf file -- I commented out the 
Include line for /var/lib/sss/pubconf/krb5.include.d/ and brought that 
data into the /etc/krb5.conf file so I only had a single file and set of 
settings to look at:


Regards,
Chris


#File modified by ipa-client-install
#includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]

default_realm = COMPANY-IDM.ORG
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}

[realms]

COMPANY-IDM.ORG = {
kdc = usaeilidmp001.COMPANY-IDM.org:88
master_kdc = usaeilidmp001.COMPANY-IDM.org:88
admin_server = usaeilidmp001.COMPANY-IDM.org:749
default_domain = COMPANY-IDM.org
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }

[domain_realm]

.COMPANY-IDM.org = COMPANY-IDM.ORG
COMPANY-IDM.org = COMPANY-IDM.ORG
.company-aws.org = COMPANY-IDM.ORG
company-aws.org = COMPANY-IDM.ORG
.company-test.org = COMPANY-IDM.ORG
company-test.org = COMPANY-IDM.ORG

[capaths]

company-aws.org = {
  COMPANY-IDM.ORG = company-aws.org

}

COMPANY-IDM.ORG = {
  company-aws.org = company-aws.org

}

company-test.org = {
COMPANY-IDM.ORG = company-test.org

}

COMPANY-IDM.ORG = {

company-test.org = company-test.org
}

--
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] Debugging SSH password-based authentication when IPA client is in a different DNS domain

[Chris Dagdigian]

Hello again,

Following up on an early query about configuring IPA clients that are in 
different DNS domains than the IPA server domain & realm


This is our setup:

AD Servers & IPA:

AD Forest #1:   company-test.org
AD Forest #2:   company-aws.org
IPA Server:   company-ipa.org

I don't really need Kerberos or Kerberized SSO -- I really just want to 
get SSH logins via passwords working before moving on to SSH keys - my 
understanding of the way I'm configuring things basically breaks 
Kerberos but should allow other user and authentication services to work.


Client Machine:
--
Hostname: client.company-aws.org

I was able to configure a client in the domain 'company-aws.org' by 
abusing the ipa-client-install command:


$ client.company-aws.org>  # ipa-client-install --server 
ipa.company-ipa.org --domain company-ipa.com


Barring the usual warnings about losing autodiscover based failover the 
above command actually worked and took me pretty far. I can launch an 
AWS host and give it the standard "company-aws.org" hostname but still 
bind it explicitly to an IPA server running in a different DNS domain 
and realm.


The nice thing is that it appears that everything but SSH w/ passwords 
is working  on the client machine with the different DNS domain name


 # id u...@company-test.org works
 # id u...@company-aws.org works
 # id  works
 # getent passwd u...@company-test.org works
 # getent passwd u...@company-aws.org works
 # getent passwd  works
 # su - u...@company-test.org works
 # su - u...@company-aws.org works
 # su -  works


What fails are things like:

 $ ssh localhost -l u...@company-aws.org

The client sees a standard "Permission Denied, please try again" error

On the client host I mainly see this in /var/log/messages:

  client.company-aws.org: [sssd[krb5_child[2311]]]: Cannot find KDC for 
realm "COMPANY-AWS.ORG"


I'm hesitant to make significant changes for fear of breaking the fact 
that my client can actually resolve users and passwords! I'm incredibly 
happy to even have the basic identities being recognized.


The problem with configuring SSH for password logins seems like it could 
be somewhere in krb5.conf, ssh_config, sshd_config, sssd.conf or even 
down in the PAM configuration and I'm not really where to start 
troubleshooting "just SSH" when everything else seems to be working OK.


Any tips, tricks or URLs for configuring the local SSH client on IPA 
clients would be appreciated. I suspect I'm a victim of either a dumb 
mistake or something that needs a manual tweak after doing an IPA client 
install where the client hostname is different from the IPA domain and 
realm.


Can provide config files and logs but did not want to spam a huge 
message in case there was a simple set of things I should be looking at



-Chris




--
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] Novice question: can client hostname be in a different DNS domain than the IPA service?

[Chris Dagdigian]

Alexander Bokovoy wrote:

You need to read this:
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
to understand all limitations and problems.

This is technical description. For higher level, see
http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/


Thank you very much! Greatly appreciate the fast and useful responses on 
this list -- the archive has been a huge help along with the RedHat IDM 
documentation.


My primary use case is SSH login for users with credentials coming from 
multiple AD Forests so it looks like I'm going down the path of "Option 
3 – Use Indirect Integration with IdM" as referenced in the 
http://rhelblog.redhat.com/2016/07/13/i-really-cant-rename-my-hosts/ 
blog posting -- seems like we lose quite a bit of Kerberos SSO features 
but for now I'm OK with that. This is Free-IPA at the moment but will be 
migrated to RHEL-IDM if successful.


Regards,
Chris






--
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] Novice question: can client hostname be in a different DNS domain than the IPA service?

[Chris Dagdigian]

Hi folks,

Working on a hairy multiple AD Forest integration issue in AWS and would 
appreciate a sanity check - I've been wrong so many times about IPA 
setup and navigating transitive AD trusts so many times I figured it was 
time to ask questions first before falling on my face again, heh.


After reading the documentation we ended up getting a new domain name to 
run our IPA server on -- seemed easier than creating and delegating a 
subdomain off of the primary AD server.


This is what we have:

AD Forest #1:   company-test.org
AD Forest #2:   company-aws.org
IPA Server:   company-ipa.org

The IPA server at company-ipa.org has successfully created 1-way trusts 
to the AD servers for company-test.org and company-aws.org


I'm at the point now where I'm ready to try installing IPA clients and 
have a simple sanity check question:


##
Can I launch a server in AWS with a hostname of "test.company-aws.org" 
yet bind it to my IPA server at "ipa.company-ipa.org" so it can manage 
users etc. ?

##

I was thinking of a command like:

# ipa-client-install \
   --domain company-aws.org \
   --server ipa.company-ipa.org \
   --realm COMPANY-AWS.ORG

Would appreciate a quick sanity check on if this is possible or 
supported. The ipa-client-install command is failing ("cant verify that 
server is an IPA server ..." ) but I'm not sure if it's because I've got 
a config / DNS / port problem or if I'm (once again) trying to do 
something stupid with IPA ...




Regards,
Chris






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