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
x=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 od
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.
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
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:
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
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
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
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:
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?
< 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
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
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
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]]
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
41 matches
Mail list logo
