That clears up a lot. The client was failing on the NSS part as no results for
the ad user were returned from the ipa master.
While cleaning cache and sss_debuglevel 10 on the master each time, testing
indicates that a different ad ldap lookup is being done from the master during
failed client
On Mon, Apr 29, 2019 at 10:32 PM Karim Bourenane via FreeIPA-users
wrote:
>
> Hello Jochen
>
> Thanks you or your reply.
> My goal, is to authenticate differents users from each client network
> interface. If the first ipa server goes down (or network unreachable), then
> the admin user can acce
Hello Jochen
Thanks you or your reply.
My goal, is to authenticate differents users from each client network
interface. If the first ipa server goes down (or network unreachable), then
the admin user can access to the second network interface to make
change/correct .
The goals also, is betwee
On Mon, Apr 29, 2019 at 07:48:30PM +, D wrote:
> Ah ok, I see the nss lookup fails on the client now.
What nss lookup exactly?
>
> On the ipa master during failed client login, the only nss log entry says my
> ad user matched the ad domain.
Did you crank up the debug logs? Chances are some
Ah ok, I see the nss lookup fails on the client now.
On the ipa master during failed client login, the only nss log entry says my ad
user matched the ad domain.
When I log in to the master with ad creds (which works), I see all of the ad
groups properly resolving in the logs (at least the ones
On ma, 29 huhti 2019, John Desantis wrote:
Alexander,
Thanks for your continued support.
I'm not saying about that at all.
Can you show output of
ipa group-show --all --raw adglobalposixgroup
Sure thing!
PROD:15:13:34-root@ipaserver1:~
# ipa group-show --all --raw adglobalposixgroup
dn:
Alexander,
Thanks for your continued support.
> I'm not saying about that at all.
>
> Can you show output of
>
> ipa group-show --all --raw adglobalposixgroup
Sure thing!
PROD:15:13:34-root@ipaserver1:~
# ipa group-show --all --raw adglobalposixgroup
dn: cn=adglobalposixgroup,cn=groups,cn=acc
On ma, 29 huhti 2019, John Desantis wrote:
Alexander,
>Yes, the group was created within the IPA domain via the cli, and this
>error is only manifest in the client log. However, the GID of the
>group (10001) is supplied via the AD trust using the POSIX range.
That isn't going to work at all.
On Mon, Apr 29, 2019 at 06:56:33PM +, D via FreeIPA-users wrote:
> Hello,
>
> Apologies for the earlier premature post :)
>
> This list helped me solve a number of issues getting a proof-of-concept
> ipa-ad cross-forest trust working. I believe there is one final issue,
> hopefully one of t
Hello,
Apologies for the earlier premature post :)
This list helped me solve a number of issues getting a proof-of-concept ipa-ad
cross-forest trust working. I believe there is one final issue, hopefully one
of the experts here can have a look at the logs and let me know if anything
sticks out
Alexander,
> >Yes, the group was created within the IPA domain via the cli, and this
> >error is only manifest in the client log. However, the GID of the
> >group (10001) is supplied via the AD trust using the POSIX range.
> That isn't going to work at all.
>
> For IPA groups POSIX IDs should be
Please disregard this post, I accidentally sent this before finishing.
Original Message
On Apr 29, 2019, 2:29 PM, D via FreeIPA-users wrote:
> Hello,
>
> This list helped solve a number of issues related to logging into clients
> under a cross-forest AD trust. I believe there i
Hello,
This list helped solve a number of issues related to logging into clients under
a cross-forest AD trust. I believe there is one final issue, I'm hoping one of
the experts can have a look at the logs and configs.
I can ssh into the IPA servers themselves using AD credentials just fine,
h
On ma, 29 huhti 2019, John Desantis via FreeIPA-users wrote:
Sumit,
Thanks for your reply.
According to the logs you send there is an error during the first
lookup when lookup up the group adglobalposixgroup:
Is this really a group from the IPA domain? If yes and the SID is really
missing (you
Sumit,
Thanks for your reply.
> According to the logs you send there is an error during the first
> lookup when lookup up the group adglobalposixgroup:
> Is this really a group from the IPA domain? If yes and the SID is really
> missing (you can check with 'ipa group-show --all adglobalposixgroup
The FreeIPA team would like to announce the first release candidate of
FreeIPA 4.8.0 release!
It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for
Fedora releases will be available in the official
[https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-8/ COPR
reposit
On ma, 29 huhti 2019, David McDaniel via FreeIPA-users wrote:
Environment:
Single Site
Two FreeIPA Idm Servers (1 Trust-Controller 1 Trust-Agent)
We ran into an issue were our Trust-Controller was offline and Kerberos
authentication began failing for AD users. We do not allow interactive
passwor
Environment:
Single Site
Two FreeIPA Idm Servers (1 Trust-Controller 1 Trust-Agent)
We ran into an issue were our Trust-Controller was offline and Kerberos
authentication began failing for AD users. We do not allow interactive password
auth. via sshd_config on IPA clients, only Pubkey or GSSAPI
On Thu, Apr 25, 2019 at 01:05:52PM -0400, John Desantis via FreeIPA-users wrote:
> Hello all,
>
> So, for anyone following this thread, I've been able to make some
> progress but not enough to consider the configuration production
> ready.
>
> After watching sssd logs ([domain] debug_level = 10,
19 matches
Mail list logo
