subject:"\[Freeipa\-users\] Mapping users from AD to IPA KDC"

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-08 Thread TomK


On 12/6/2016 3:37 PM, Alexander Bokovoy wrote:

On ti, 06 joulu 2016, TomK wrote:

On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).

Nothing I tried in AD Trust creation allowed me to make one with type
Forest.  Just realm.  I recall I had a trust type of Forest but in
trying various options I lost how I did that.  Or perhaps I hadn't
payed attention and it got created indirectly as part of another
action I took.  The domain functional level I'm using is Windows
Server 2008. Using a lower value for testing.

This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.

Removed the incorrect trust and recreated per your online pages.  This 
time forest was visible.




My IPA version is 4.2 right now.  It came with the CentOS 7.2.
Looking forward to 4.4.  Not sure when you plan to include it as part
of the latest CentOS base.  Indeed some ports were not open (445).
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:

for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd
--zone=public --permanent --add-port=$KEY; done

[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
 interfaces:
 sources:
 services: dhcpv6-client ntp ssh
 ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp
139/udp 138/udp 53/udp 636/tcp
 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the
firewall change however.):

Firewall changes cannot affect DNS as you already had DNS port open.


On the AD side, I added the SRV records for the second AD DC,
manually, since earlier there were no results printed on the AD DC
command line for the second AD DC, when I typed the command
_ldap._tcp.mds.xyz.

One additional question I had with the setup is in regards to the
failover.  I see the ipa_server entry in /etc/sssd/sssd.conf pointing
to two of the master IPA nodes.  Where can I find the additional
settings that control priority of the listed server or order they are
checked?

You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w ""
--fixed-primary --server=idmipa01.nix.mds.xyz
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U
2) realm join mds.xyz

This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.




Sending you a document with the details.

--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free tri

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-07 Thread TomK


On 12/6/2016 11:32 PM, TomK wrote:

On 12/6/2016 3:37 PM, Alexander Bokovoy wrote:

On ti, 06 joulu 2016, TomK wrote:

On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).

Nothing I tried in AD Trust creation allowed me to make one with type
Forest.  Just realm.  I recall I had a trust type of Forest but in
trying various options I lost how I did that.  Or perhaps I hadn't
payed attention and it got created indirectly as part of another
action I took.  The domain functional level I'm using is Windows
Server 2008. Using a lower value for testing.

This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.



My IPA version is 4.2 right now.  It came with the CentOS 7.2.
Looking forward to 4.4.  Not sure when you plan to include it as part
of the latest CentOS base.  Indeed some ports were not open (445).
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:

for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd
--zone=public --permanent --add-port=$KEY; done

[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
 interfaces:
 sources:
 services: dhcpv6-client ntp ssh
 ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp
139/udp 138/udp 53/udp 636/tcp
 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the
firewall change however.):

Firewall changes cannot affect DNS as you already had DNS port open.


On the AD side, I added the SRV records for the second AD DC,
manually, since earlier there were no results printed on the AD DC
command line for the second AD DC, when I typed the command
_ldap._tcp.mds.xyz.

One additional question I had with the setup is in regards to the
failover.  I see the ipa_server entry in /etc/sssd/sssd.conf pointing
to two of the master IPA nodes.  Where can I find the additional
settings that control priority of the listed server or order they are
checked?

You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w ""
--fixed-primary --server=idmipa01.nix.mds.xyz
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz
--realm=NIX.MDS.XYZ -U
2) realm join mds.xyz

This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.





Ok, let me take these away and get back to you.  ( On realm, thank you.
Hadn't reviewed the changes it did fully before logging off. )



Removed the direct mds.xyz domain directly (my bad).  Currently I get 
this on using MDS.XYZ\tom to login with or t...@mds.xyz

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-06 Thread List dedicated to discussions about use, configuration and deployment of the IPA server.


On 12/6/2016 3:37 PM, Alexander Bokovoy wrote:

On ti, 06 joulu 2016, TomK wrote:

On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).

Nothing I tried in AD Trust creation allowed me to make one with type
Forest.  Just realm.  I recall I had a trust type of Forest but in
trying various options I lost how I did that.  Or perhaps I hadn't
payed attention and it got created indirectly as part of another
action I took.  The domain functional level I'm using is Windows
Server 2008. Using a lower value for testing.

This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.



My IPA version is 4.2 right now.  It came with the CentOS 7.2.
Looking forward to 4.4.  Not sure when you plan to include it as part
of the latest CentOS base.  Indeed some ports were not open (445).
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:

for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd
--zone=public --permanent --add-port=$KEY; done

[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
 interfaces:
 sources:
 services: dhcpv6-client ntp ssh
 ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp
139/udp 138/udp 53/udp 636/tcp
 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the
firewall change however.):

Firewall changes cannot affect DNS as you already had DNS port open.


On the AD side, I added the SRV records for the second AD DC,
manually, since earlier there were no results printed on the AD DC
command line for the second AD DC, when I typed the command
_ldap._tcp.mds.xyz.

One additional question I had with the setup is in regards to the
failover.  I see the ipa_server entry in /etc/sssd/sssd.conf pointing
to two of the master IPA nodes.  Where can I find the additional
settings that control priority of the listed server or order they are
checked?

You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w ""
--fixed-primary --server=idmipa01.nix.mds.xyz
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ -U
2) realm join mds.xyz

This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.





Ok, let me take these away and get back to you.  ( On realm, thank you. 
Hadn't reviewed the changes it did fully before logging off. )


--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-06 Thread List dedicated to discussions about use, configuration and deployment of the IPA server.


On ti, 06 joulu 2016, TomK wrote:

On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).
Nothing I tried in AD Trust creation allowed me to make one with type 
Forest.  Just realm.  I recall I had a trust type of Forest but in 
trying various options I lost how I did that.  Or perhaps I hadn't 
payed attention and it got created indirectly as part of another 
action I took.  The domain functional level I'm using is Windows 
Server 2008. Using a lower value for testing.

This (inability to chose Forest trust type) simply means AD DC is unable
to probe IPA DC. You said below that SMB port towards IPA DC was closed.

Also make sure to remove incorrect trust from Windows side. While we are
removing a trust object named as our NetBIOS name, it only works for the
proper trusted domain/forests, not for wrong 'realm trust' type.



My IPA version is 4.2 right now.  It came with the CentOS 7.2.  
Looking forward to 4.4.  Not sure when you plan to include it as part 
of the latest CentOS base.  Indeed some ports were not open (445).  
I've adjusted the firewall command accordingly for RHEL 7 / CentOS 7:


for KEY in $(echo "80/tcp 443/tcp 389/tcp 636/tcp 88/tcp 464/tcp 
53/tcp 135/tcp 138/tcp 139/tcp 445/tcp 1024-1300/tcp 88/udp 464/udp 
53/udp 123/udp 138/udp 139/udp 389/udp 445/udp"); do firewall-cmd 
--zone=public --permanent --add-port=$KEY; done


[root@idmipa01 ~]# firewall-cmd --zone=public --list-all
public (default)
 interfaces:
 sources:
 services: dhcpv6-client ntp ssh
 ports: 443/tcp 80/tcp 464/tcp 138/tcp 88/udp 464/udp 445/tcp 88/tcp 
135/tcp 123/udp 139/tcp 389/tcp 53/tcp 389/udp 1024-1300/tcp 445/udp 
139/udp 138/udp 53/udp 636/tcp

 masquerade: no
 forward-ports:
 icmp-blocks:
 rich rules:

[root@idmipa01 ~]#

On Windows Side (The nslookup results were the same before the 
firewall change however.):

Firewall changes cannot affect DNS as you already had DNS port open.

On the AD side, I added the SRV records for the second AD DC, 
manually, since earlier there were no results printed on the AD DC 
command line for the second AD DC, when I typed the command 
_ldap._tcp.mds.xyz.


One additional question I had with the setup is in regards to the 
failover.  I see the ipa_server entry in /etc/sssd/sssd.conf pointing 
to two of the master IPA nodes.  Where can I find the additional 
settings that control priority of the listed server or order they are 
checked?

You need to look at SSSD manual pages: sssd-ipa and sssd-ldap, sections
FAILOVER and SERVICE DISCOVER.


What I ran to get the above is:

1) ipa-client-install --force-join -p admin -w "" 
--fixed-primary --server=idmipa01.nix.mds.xyz 
--server=idmipa02.nix.mds.xyz --domain=nix.mds.xyz --realm=NIX.MDS.XYZ 
-U

2) realm join mds.xyz

This is wrong. You have effectively joined this IPA client to AD and IPA
at the same time. It should not be done this way (read
http://www.freeipa.org/page/V4/IPA_Client_in_Active_Directory_DNS_domain
for details).

Instead, you need to identify why the trust does not work properly.
Use tcpdump to intercept the traffic between your AD DCs and IPA DCs
while establishing the trust.

You can send the trace to me off-list.



--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-05 Thread TomK


On 12/5/2016 2:02 AM, Alexander Bokovoy wrote:

On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run
this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a
non-transitive trust, the above did NOT work.  I didn't get anything
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust
as the gif on this page suggests:
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly
it's Server 2012 hence the difference in what's presented to me but
another reason is that the name I type for the trust can't resolve to
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).
Nothing I tried in AD Trust creation allowed me to make one with type 
Forest.  Just realm.  I recall I had a trust type of Forest but in 
trying various options I lost how I did that.  Or perhaps I hadn't payed 
attention and it got created indirectly as part of another action I 
took.  The domain functional level I'm using is Windows Server 2008. 
Using a lower value for testing.





I went back to the trust object in AD and set it to Transitive from
Non-transitive.  And all of a sudden I can resolve the AD ID's on the
IP Servers and all is working fine.  Great!

I could not follow the section within the online document above for
setting up forwarders.  I had to delegate nix.mds.xyz from the two AD
/ DNS Clustered Windows Server 2012 servers to the two FreeIPA servers
(idmipa01, idmipa02) .  I found that the forwarding section doesn't
quite jive well with delegation in Windows Server 2012.

Whatever you do to forward DNS in a DNS-compliant way should be enough.
The documentation typically tries to explain that there are multiple
ways to achieve this, from hackish to standards-compliant.


The remaining questions I need to ask is does the NetBIOS name used on
the ipa-adtrust-install command above have to match the AD DC Trust
object name?  Any tie's between the naming of the two?  ( Thinking no
tie in but not 100% . Seems AD expects a domain that resolves to an IP )

100% tied, this is AD requirement.

Each domain has domain name in NetBIOS, domain name in DNS, and SID. The
first two must be matching and on DNS level AD expects both to resolve
properly. It is a legacy from NT times that _all_ trusted domain objects
are named as NetBIOS$, as well as _all_ computer objects have the same
style names COMPUTER$. This is enforced on multiple levels, from SMB to
Kerberos.

What 'resolve' means here is that DNS searches for different types of
SRV records should succeed, and then CLDAP ping to the servers which are
mentioned in the
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.$DOMAIN
or _ldap._tcp.dc._msdcs.$DOMAIN should succeed too.



Also, given this setup I have:

1) The two windows servers, winad01, winad02 are both DNS, AD servers
and are clustered (NLB)

2) Have DNS delegation on nix.mds.xyz so FreeIPA servers will be
authoritative for that subdomain.

3) AD Trust objects look for a resolvable domain (ie nix.mds.xyz) and
current version of FreeIPA does not yet resolve nix.mds.xyz to any IP

No, this is not required. What required, is that trust object is
correctly set, and it involves a lot more than what you are outlining.
As you can see above, resolving nix.mds.xyz to IP is not required, but
DNS SRV records like _ldap._tcp.dc._msdcs.nix.mds.xyz should be
resolvable.


4) IPA ipa-adtrust-install only accepts NetBIOS names.

ipa-adtrust-install configures what is missing from the base setup
related to the trust to AD. NetBIOS name is missing, thus is added.



Is it at all possible to setup a non-transitive trust with all that?
( I might just not be seeing the forest through the trees  :) - Pun
Intended. )   Still new to quite a bit of this so thank you for your
patience and feedback.

Non-transitive trust is called 'external trust' in AD jargon. It can be
established to any domain in a forest. We support it from FreeIPA 4.4
with --external=true option to 'ipa trust-add'.

With non-transitive trust only users from directly trusted domain can be
seen and authenticated

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-04 Thread Alexander Bokovoy


On su, 04 joulu 2016, TomK wrote:

Could not get much from logs and decided to start fresh.  When I run this:

ipa trust-add --type=ad mds.xyz --admin Administrator --password

Trust works fine and id t...@mds.xyz returns a valid result.

However when I run the following on both masters on a fresh new setup:

ipa-adtrust-install --netbios-name=NIX -a ""
ipa trust-add --type=ad "mds.xyz" --trust-secret

and created a trust object in AD DC with the name of NIX and a 
non-transitive trust, the above did NOT work.  I didn't get anything 
by typing id t...@mds.xyz.  (I do not get an option for a Forest Trust 
as the gif on this page suggests: 
https://www.freeipa.org/page/Active_Directory_trust_setup .  Possibly 
it's Server 2012 hence the difference in what's presented to me but 
another reason is that the name I type for the trust can't resolve to 
an IP for now: nix.mds.xyz . So I use NIX to match the bios name used 
on the ipa-adtrust-install command above.  )

The shared secret case for one-way trust is known to be broken. When a
shared half is created on AD side first, it is marked as not yet valid
by Windows and currently we cannot perform validation of it from IPA
side. Validating it from AD side is not possible as well as we don't
provide all interfaces Windows would like to use.

And the fact you cannot see 'Forest Trust' type of the trust says also
that you have problems with reaching IPA masters from AD DC side for
probing purposes over CLDAP ping (389/UDP) and then SMB (445/TCP and
UDP).

I went back to the trust object in AD and set it to Transitive from 
Non-transitive.  And all of a sudden I can resolve the AD ID's on the 
IP Servers and all is working fine.  Great!


I could not follow the section within the online document above for 
setting up forwarders.  I had to delegate nix.mds.xyz from the two AD 
/ DNS Clustered Windows Server 2012 servers to the two FreeIPA servers 
(idmipa01, idmipa02) .  I found that the forwarding section doesn't 
quite jive well with delegation in Windows Server 2012.

Whatever you do to forward DNS in a DNS-compliant way should be enough.
The documentation typically tries to explain that there are multiple
ways to achieve this, from hackish to standards-compliant.

The remaining questions I need to ask is does the NetBIOS name used on 
the ipa-adtrust-install command above have to match the AD DC Trust 
object name?  Any tie's between the naming of the two?  ( Thinking no 
tie in but not 100% . Seems AD expects a domain that resolves to an IP 
)

100% tied, this is AD requirement.

Each domain has domain name in NetBIOS, domain name in DNS, and SID. The
first two must be matching and on DNS level AD expects both to resolve
properly. It is a legacy from NT times that _all_ trusted domain objects
are named as NetBIOS$, as well as _all_ computer objects have the same
style names COMPUTER$. This is enforced on multiple levels, from SMB to
Kerberos.

What 'resolve' means here is that DNS searches for different types of
SRV records should succeed, and then CLDAP ping to the servers which are
mentioned in the _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.$DOMAIN
or _ldap._tcp.dc._msdcs.$DOMAIN should succeed too.



Also, given this setup I have:

1) The two windows servers, winad01, winad02 are both DNS, AD servers 
and are clustered (NLB)


2) Have DNS delegation on nix.mds.xyz so FreeIPA servers will be 
authoritative for that subdomain.


3) AD Trust objects look for a resolvable domain (ie nix.mds.xyz) and 
current version of FreeIPA does not yet resolve nix.mds.xyz to any IP 

No, this is not required. What required, is that trust object is
correctly set, and it involves a lot more than what you are outlining.
As you can see above, resolving nix.mds.xyz to IP is not required, but
DNS SRV records like _ldap._tcp.dc._msdcs.nix.mds.xyz should be
resolvable.


4) IPA ipa-adtrust-install only accepts NetBIOS names.

ipa-adtrust-install configures what is missing from the base setup
related to the trust to AD. NetBIOS name is missing, thus is added.



Is it at all possible to setup a non-transitive trust with all that?  
( I might just not be seeing the forest through the trees  :) - Pun 
Intended. )   Still new to quite a bit of this so thank you for your 
patience and feedback.

Non-transitive trust is called 'external trust' in AD jargon. It can be
established to any domain in a forest. We support it from FreeIPA 4.4
with --external=true option to 'ipa trust-add'.

With non-transitive trust only users from directly trusted domain can be
seen and authenticated.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-04 Thread TomK


On 12/3/2016 12:57 PM, TomK wrote:

On 12/3/2016 12:33 AM, TomK wrote:

On 12/2/2016 8:43 AM, Sumit Bose wrote:

On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote:

Hey All,

I've successfully mapped the nixadmins to the external group
nixadmins_external.  However no users in that group make it over to
Free IPA
that I can see.

ipa group-add-member nixadmins_external --external "nixadmins"

Windows AD users, 3 of them, are in the windows AD group nixadmins.
However
I can't port them over.

These accounts have UNIX attributes assigned to them.

Question that I have and can't find, should I be seeing these users
in the
mapped groups above?  ( ie within the GUI should I see any users
listed from
AD DC in nixadmins or nixadmins_external? )


no, the GUI won't show them. Calling 'id user_from_nixadmins@ad.domain'
should show that nixadmins_external is a member of that group. With
recent version of SSSD 'getent group nixadmins_external' should list the
users from nixadmins as well, older versions might miss them.

HTH

bye,
Sumit



If there is an issue and I'm just not picking it out from the debug
logs,
what to look for?  Is there anything more I need to do on the Windows
side
that I haven't found on the existing pages?


# ipa group-add-member nixadmins_external --external "nixadmins"
[member user]:
[member group]:
  Group name: nixadmins_external
  Description: NIX Admins External map
  External member: S-1-5-21-3418825849-1633701630-2291579631-1006
  Member groups: nixadmins
  Member of groups: nixadmins
  Indirect Member groups: nixadmins_external
-
Number of members added 1
-
#


# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1

#


[realms]
 DOM.ABC.XYZ = {
.
.
.
  auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/
  auth_to_local = DEFAULT
}


# ipa trust-fetch-domains abc.xyz



List of trust domains successfully refreshed. Use trustdomain-find
command
to list them.




Number of entries returned 0

[root@idmipa01 sssd]# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1



# ipa trust-fetch-domains abc.xyz



List of trust domains successfully refreshed. Use trustdomain-find
command
to list them.




Number of entries returned 0

#


The following command successfully returns all AD objects under the
Users
cn.

# ldapsearch -x -h 192.168.0.3 -D "t...@abc.xyz" -W -b
"cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn


--
Cheers,
Tom K.
-



Living on earth is expensive, but it includes a free trip around the
sun.

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




Nothing:

# id t...@abc.xyz
id: t...@abc.xyz: no such user
# getent group nixadmins_external
# getent group nixadmins
nixadmins:*:1746600012:
#

I'll enable debug logging to determine further.



I'm getting the following in the logs. Not sure why it cannot assign a
GID (possibly a range mismatch) but my dnaRemainingValues: 99498 and so
is fine:

[2016/12/03 10:45:44.232656,  3, pid=4792, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_allocate_gid.c:45(winbindd_allocate_gid_send)
  allocate_gid
[2016/12/03 10:45:44.232689,  1, pid=4792, effective(0, 0), real(0, 0)]
../librpc/ndr/ndr.c:439(ndr_print_function_debug)
   wbint_AllocateGid: struct wbint_AllocateGid
  in: struct wbint_AllocateGid
[2016/12/03 10:45:44.233134,  1, pid=4792, effective(0, 0), real(0, 0)]
../librpc/ndr/ndr.c:439(ndr_print_function_debug)
   wbint_AllocateGid: struct wbint_AllocateGid
  out: struct wbint_AllocateGid
  gid  : *
  gid  : 0x (0)
  result   : NT_STATUS_UNSUCCESSFUL
[2016/12/03 10:45:44.233192,  5, pid=4792, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_allocate_gid.c:83(winbindd_allocate_gid_recv)
  Could not allocate gid: NT_STATUS_

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-03 Thread TomK


On 12/3/2016 12:33 AM, TomK wrote:

On 12/2/2016 8:43 AM, Sumit Bose wrote:

On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote:

Hey All,

I've successfully mapped the nixadmins to the external group
nixadmins_external.  However no users in that group make it over to
Free IPA
that I can see.

ipa group-add-member nixadmins_external --external "nixadmins"

Windows AD users, 3 of them, are in the windows AD group nixadmins.
However
I can't port them over.

These accounts have UNIX attributes assigned to them.

Question that I have and can't find, should I be seeing these users
in the
mapped groups above?  ( ie within the GUI should I see any users
listed from
AD DC in nixadmins or nixadmins_external? )


no, the GUI won't show them. Calling 'id user_from_nixadmins@ad.domain'
should show that nixadmins_external is a member of that group. With
recent version of SSSD 'getent group nixadmins_external' should list the
users from nixadmins as well, older versions might miss them.

HTH

bye,
Sumit



If there is an issue and I'm just not picking it out from the debug
logs,
what to look for?  Is there anything more I need to do on the Windows
side
that I haven't found on the existing pages?


# ipa group-add-member nixadmins_external --external "nixadmins"
[member user]:
[member group]:
  Group name: nixadmins_external
  Description: NIX Admins External map
  External member: S-1-5-21-3418825849-1633701630-2291579631-1006
  Member groups: nixadmins
  Member of groups: nixadmins
  Indirect Member groups: nixadmins_external
-
Number of members added 1
-
#


# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1

#


[realms]
 DOM.ABC.XYZ = {
.
.
.
  auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/
  auth_to_local = DEFAULT
}


# ipa trust-fetch-domains abc.xyz


List of trust domains successfully refreshed. Use trustdomain-find
command
to list them.



Number of entries returned 0

[root@idmipa01 sssd]# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1



# ipa trust-fetch-domains abc.xyz


List of trust domains successfully refreshed. Use trustdomain-find
command
to list them.



Number of entries returned 0

#


The following command successfully returns all AD objects under the
Users
cn.

# ldapsearch -x -h 192.168.0.3 -D "t...@abc.xyz" -W -b
"cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn


--
Cheers,
Tom K.
-


Living on earth is expensive, but it includes a free trip around the
sun.

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




Nothing:

# id t...@abc.xyz
id: t...@abc.xyz: no such user
# getent group nixadmins_external
# getent group nixadmins
nixadmins:*:1746600012:
#

I'll enable debug logging to determine further.



I'm getting the following in the logs. Not sure why it cannot assign a 
GID (possibly a range mismatch) but my dnaRemainingValues: 99498 and so 
is fine:


[2016/12/03 10:45:44.232656,  3, pid=4792, effective(0, 0), real(0, 0), 
class=winbind] 
../source3/winbindd/winbindd_allocate_gid.c:45(winbindd_allocate_gid_send)

  allocate_gid
[2016/12/03 10:45:44.232689,  1, pid=4792, effective(0, 0), real(0, 0)] 
../librpc/ndr/ndr.c:439(ndr_print_function_debug)

   wbint_AllocateGid: struct wbint_AllocateGid
  in: struct wbint_AllocateGid
[2016/12/03 10:45:44.233134,  1, pid=4792, effective(0, 0), real(0, 0)] 
../librpc/ndr/ndr.c:439(ndr_print_function_debug)

   wbint_AllocateGid: struct wbint_AllocateGid
  out: struct wbint_AllocateGid
  gid  : *
  gid  : 0x (0)
  result   : NT_STATUS_UNSUCCESSFUL
[2016/12/03 10:45:44.233192,  5, pid=4792, effective(0, 0), real(0, 0), 
class=winbind] 
../source3/winbindd/winbindd_allocate_gid.c:83(winbindd_allocate_gid_recv)

  Could not allocate gid: NT_STATUS_UNSUCCESSFUL
[2016/12/03 10:

Re: [Freeipa-users] Mapping users from AD to IPA KDC

2016-12-02 Thread TomK


On 12/2/2016 8:43 AM, Sumit Bose wrote:

On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote:

Hey All,

I've successfully mapped the nixadmins to the external group
nixadmins_external.  However no users in that group make it over to Free IPA
that I can see.

ipa group-add-member nixadmins_external --external "nixadmins"

Windows AD users, 3 of them, are in the windows AD group nixadmins. However
I can't port them over.

These accounts have UNIX attributes assigned to them.

Question that I have and can't find, should I be seeing these users in the
mapped groups above?  ( ie within the GUI should I see any users listed from
AD DC in nixadmins or nixadmins_external? )


no, the GUI won't show them. Calling 'id user_from_nixadmins@ad.domain'
should show that nixadmins_external is a member of that group. With
recent version of SSSD 'getent group nixadmins_external' should list the
users from nixadmins as well, older versions might miss them.

HTH

bye,
Sumit



If there is an issue and I'm just not picking it out from the debug logs,
what to look for?  Is there anything more I need to do on the Windows side
that I haven't found on the existing pages?


# ipa group-add-member nixadmins_external --external "nixadmins"
[member user]:
[member group]:
  Group name: nixadmins_external
  Description: NIX Admins External map
  External member: S-1-5-21-3418825849-1633701630-2291579631-1006
  Member groups: nixadmins
  Member of groups: nixadmins
  Indirect Member groups: nixadmins_external
-
Number of members added 1
-
#


# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1

#


[realms]
 DOM.ABC.XYZ = {
.
.
.
  auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/
  auth_to_local = DEFAULT
}


# ipa trust-fetch-domains abc.xyz

List of trust domains successfully refreshed. Use trustdomain-find command
to list them.


Number of entries returned 0

[root@idmipa01 sssd]# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1



# ipa trust-fetch-domains abc.xyz

List of trust domains successfully refreshed. Use trustdomain-find command
to list them.


Number of entries returned 0

#


The following command successfully returns all AD objects under the Users
cn.

# ldapsearch -x -h 192.168.0.3 -D "t...@abc.xyz" -W -b
"cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn


--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.

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




Nothing:

# id t...@abc.xyz
id: t...@abc.xyz: no such user
# getent group nixadmins_external
# getent group nixadmins
nixadmins:*:1746600012:
#

I'll enable debug logging to determine further.

--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.

--
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] Mapping users from AD to IPA KDC

2016-12-02 Thread Sumit Bose

On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote:
> Hey All,
> 
> I've successfully mapped the nixadmins to the external group
> nixadmins_external.  However no users in that group make it over to Free IPA
> that I can see.
> 
> ipa group-add-member nixadmins_external --external "nixadmins"
> 
> Windows AD users, 3 of them, are in the windows AD group nixadmins. However
> I can't port them over.
> 
> These accounts have UNIX attributes assigned to them.
> 
> Question that I have and can't find, should I be seeing these users in the
> mapped groups above?  ( ie within the GUI should I see any users listed from
> AD DC in nixadmins or nixadmins_external? )

no, the GUI won't show them. Calling 'id user_from_nixadmins@ad.domain'
should show that nixadmins_external is a member of that group. With
recent version of SSSD 'getent group nixadmins_external' should list the
users from nixadmins as well, older versions might miss them.

HTH

bye,
Sumit

> 
> If there is an issue and I'm just not picking it out from the debug logs,
> what to look for?  Is there anything more I need to do on the Windows side
> that I haven't found on the existing pages?
> 
> 
> # ipa group-add-member nixadmins_external --external "nixadmins"
> [member user]:
> [member group]:
>   Group name: nixadmins_external
>   Description: NIX Admins External map
>   External member: S-1-5-21-3418825849-1633701630-2291579631-1006
>   Member groups: nixadmins
>   Member of groups: nixadmins
>   Indirect Member groups: nixadmins_external
> -
> Number of members added 1
> -
> #
> 
> 
> # ipa trustdomain-find abc.xyz
>   Domain name: abc.xyz
>   Domain NetBIOS name: ABC
>   Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
>   Domain enabled: True
> 
> Number of entries returned 1
> 
> #
> 
> 
> [realms]
>  DOM.ABC.XYZ = {
> .
> .
> .
>   auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/
>   auth_to_local = DEFAULT
> }
> 
> 
> # ipa trust-fetch-domains abc.xyz
> 
> List of trust domains successfully refreshed. Use trustdomain-find command
> to list them.
> 
> 
> Number of entries returned 0
> 
> [root@idmipa01 sssd]# ipa trustdomain-find abc.xyz
>   Domain name: abc.xyz
>   Domain NetBIOS name: ABC
>   Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
>   Domain enabled: True
> 
> Number of entries returned 1
> 
> 
> 
> # ipa trust-fetch-domains abc.xyz
> 
> List of trust domains successfully refreshed. Use trustdomain-find command
> to list them.
> 
> 
> Number of entries returned 0
> 
> #
> 
> 
> The following command successfully returns all AD objects under the Users
> cn.
> 
> # ldapsearch -x -h 192.168.0.3 -D "t...@abc.xyz" -W -b
> "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn
> 
> 
> -- 
> Cheers,
> Tom K.
> -
> 
> Living on earth is expensive, but it includes a free trip around the sun.
> 
> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Mapping users from AD to IPA KDC

2016-12-02 Thread TomK


Hey All,

I've successfully mapped the nixadmins to the external group 
nixadmins_external.  However no users in that group make it over to Free 
IPA that I can see.


ipa group-add-member nixadmins_external --external "nixadmins"

Windows AD users, 3 of them, are in the windows AD group nixadmins. 
However I can't port them over.


These accounts have UNIX attributes assigned to them.

Question that I have and can't find, should I be seeing these users in 
the mapped groups above?  ( ie within the GUI should I see any users 
listed from AD DC in nixadmins or nixadmins_external? )


If there is an issue and I'm just not picking it out from the debug 
logs, what to look for?  Is there anything more I need to do on the 
Windows side that I haven't found on the existing pages?



# ipa group-add-member nixadmins_external --external "nixadmins"
[member user]:
[member group]:
  Group name: nixadmins_external
  Description: NIX Admins External map
  External member: S-1-5-21-3418825849-1633701630-2291579631-1006
  Member groups: nixadmins
  Member of groups: nixadmins
  Indirect Member groups: nixadmins_external
-
Number of members added 1
-
#


# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1

#


[realms]
 DOM.ABC.XYZ = {
.
.
.
  auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/
  auth_to_local = DEFAULT
}


# ipa trust-fetch-domains abc.xyz

List of trust domains successfully refreshed. Use trustdomain-find 
command to list them.



Number of entries returned 0

[root@idmipa01 sssd]# ipa trustdomain-find abc.xyz
  Domain name: abc.xyz
  Domain NetBIOS name: ABC
  Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
  Domain enabled: True

Number of entries returned 1



# ipa trust-fetch-domains abc.xyz

List of trust domains successfully refreshed. Use trustdomain-find 
command to list them.



Number of entries returned 0

#


The following command successfully returns all AD objects under the 
Users cn.


# ldapsearch -x -h 192.168.0.3 -D "t...@abc.xyz" -W -b 
"cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn



--
Cheers,
Tom K.
-

Living on earth is expensive, but it includes a free trip around the sun.

--
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] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

Re: [Freeipa-users] Mapping users from AD to IPA KDC

[Freeipa-users] Mapping users from AD to IPA KDC

11 matches

Site Navigation

Mail list logo

Footer information