Re: [Freeipa-users] confused about replica role and use

[Alexander Bokovoy]

On Wed, 16 Dec 2015, Karl Forner wrote:


If you do a local login instead of a kinit, you will see that SSSD will
switch to the new server and subsequent kinit will start using it.



Ok, I checked and it works just fine for me, thanks.

This dynamic discovery of freeipa servers by sssd is very elegant and
smart;
but I still do not understand how do you automatically switch to a replica
(ipa2) if your master (ipa1) is down
in some cases:

- to access the freeipa web ui. You have to use an url, e.g.
https://ipa1.example.com
If ipa1 is down, how do you know which url to use ?

We have no mechanism for that. Hiding IPA web ui behind a balancer is
not easy -- Kerberos does not really like balancers. You can search
archives of this list to know more.


- if you have other web apps that authenticate against the freeIPA LDAP
server.
Usually you have to provide a ldap url in the web app configuration, e.g.
ldap://ipa1.example.com.
What happens when ipa1 is down ?

That's easy and there are two different approaches here:
1. Use SSSD instead of directly talking to FreeIPA LDAP as we describe
and recommend on https://www.freeipa.org/page/Web_App_Authentication
2. Use SRV discovery syntax built-in to openldap's tools.

The latter is somewhat less known feature mandated by RFC 4516:
http://www.rfc-editor.org/rfc/rfc4516.txt

It is achieved with -H option of ldapsearch or other ldap tools if you
don't specify a host but rather use DN: dc=example,dc=com, encoded in a
way of RFC 2396: dc%3Dexample%2Cdc%3Dcom

where %3D is escape sequence for '=' and %2C is escape sequence for ','

ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom

would request ldapsearch to first go and resolve DNS SRV record
_ldap._tcp.example.com and then connect to the list of servers returned.

All tools from OpenLDAP client side use this technique and rotate over
list of servers. You can specify multiple servers yourself too as

  -H "ldap://ipa1.example.com ldap://ipa2.example.com ldap://ipa3.example.com;

but using DNS SRV records is more reliable because you don't need to
change your script when you decommission the servers.

However, the first syntax will not work for just any application using
libldap as they don't do this additional SRV discovery. Instead, the
second approach should work for them by passing a list of servers
separated by space instead of a single one. Again, this is LDAP library
specific and not all libraries support this. This is why we recommend
you actually use SSSD. :)

--
/ 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] confused about replica role and use

[Simo Sorce]

On Wed, 2015-12-16 at 18:34 +0100, Karl Forner wrote:
> > SSSD mostly manages discovery of servers, it is normally configure with
> > the name _srv_ + an actual name as fallback.
> > SSSD also feeds the information to kerberos libraries via a plugin.
> 
> ok, I have this line in my /etc/sssd/sssd.conf:
> ipa_server = _srv_, ipa.example.com
> 
> How do I check the current ipa_servers picked up by sssd ?
> How do the info is fed to kerberos libraries ?
> 
> Because I set up a replica, using the adelton docker, which seems to work
> fine. I can use its DNS, access its web UI, the changes are dynamically
> updated both ways.
> So far so good.
> But if suddenly stops the freeIPA master, and try a kdestroy then kinit on
> my client, I get
> kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial
> credentials
> 
> Looking at /etc/krb5.conf, I see hardcoded values:
>  #File modified by ipa-client-install
> 
> includedir /var/lib/sss/pubconf/krb5.include.d/
> 
> [libdefaults]
>   default_realm = EXAMPLE.COM
>   dns_lookup_realm = false
>   dns_lookup_kdc = false
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
> 
> [realms]
>   EXAMPLE.COM = {
> kdc = ipa.example.com:88
> master_kdc = ipa.example.com:88
> admin_server = ipa.example.com:749
> default_domain = example.com
> pkinit_anchors = FILE:/etc/ipa/ca.crt
>   }
> 
> [domain_realm]
>   .EXAMPLE.com = EXAMPLE.COM
>   EXAMPLE.com = EXAMPLE.COM
> 
> the same for /etc/ipa/default.conf:
> #File modified by ipa-client-install
> 
> [global]
> basedn = dc=example,dc=com
> realm = EXAMPLE.COM
> domain = example.com
> server = ipah.example.com
> xmlrpc_uri = https://ipah.example.com/ipa/xml
> enable_ra = True
> 
> 
> Is this expected ?

Unfortunately it is, it is a bug in the way we update the krb5 libraries
to point to a KDC.

SSSD updates this information in a file under /var/lib/sss/pubconf and
krb5 libraries read from it, however kinit cannot force sssd to
re-evaluate if the file needs updating.

If you do a local login instead of a kinit, you will see that SSSD will
switch to the new server and subsequent kinit will start using it.

This is tracked here:
https://fedorahosted.org/sssd/ticket/941

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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] confused about replica role and use

[Karl Forner]

>
> If you do a local login instead of a kinit, you will see that SSSD will
> switch to the new server and subsequent kinit will start using it.
>

Ok, I checked and it works just fine for me, thanks.

This dynamic discovery of freeipa servers by sssd is very elegant and
smart;
but I still do not understand how do you automatically switch to a replica
(ipa2) if your master (ipa1) is down
in some cases:

 - to access the freeipa web ui. You have to use an url, e.g.
https://ipa1.example.com
 If ipa1 is down, how do you know which url to use ?

 - if you have other web apps that authenticate against the freeIPA LDAP
server.
 Usually you have to provide a ldap url in the web app configuration, e.g.
ldap://ipa1.example.com.
 What happens when ipa1 is down ?

Karl


> This is tracked here:
> https://fedorahosted.org/sssd/ticket/941
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
>
-- 
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] confused about replica role and use

[Karl Forner]

> SSSD mostly manages discovery of servers, it is normally configure with
> the name _srv_ + an actual name as fallback.
> SSSD also feeds the information to kerberos libraries via a plugin.

ok, I have this line in my /etc/sssd/sssd.conf:
ipa_server = _srv_, ipa.example.com

How do I check the current ipa_servers picked up by sssd ?
How do the info is fed to kerberos libraries ?

Because I set up a replica, using the adelton docker, which seems to work
fine. I can use its DNS, access its web UI, the changes are dynamically
updated both ways.
So far so good.
But if suddenly stops the freeIPA master, and try a kdestroy then kinit on
my client, I get
kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial
credentials

Looking at /etc/krb5.conf, I see hardcoded values:
 #File modified by ipa-client-install

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = EXAMPLE.COM
  dns_lookup_realm = false
  dns_lookup_kdc = false
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes

[realms]
  EXAMPLE.COM = {
kdc = ipa.example.com:88
master_kdc = ipa.example.com:88
admin_server = ipa.example.com:749
default_domain = example.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
  }

[domain_realm]
  .EXAMPLE.com = EXAMPLE.COM
  EXAMPLE.com = EXAMPLE.COM

the same for /etc/ipa/default.conf:
#File modified by ipa-client-install

[global]
basedn = dc=example,dc=com
realm = EXAMPLE.COM
domain = example.com
server = ipah.example.com
xmlrpc_uri = https://ipah.example.com/ipa/xml
enable_ra = True


Is this expected ?

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

Re: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates

[Alexander Bokovoy]

On Wed, 16 Dec 2015, Harald Dunkel wrote:

On 12/15/2015 04:04 PM, Alexander Bokovoy wrote:


It makes possible others to see your specific details as this is the
first time we get such bug report.


Done: https://bugzilla.redhat.com/show_bug.cgi?id=1292042

Now what would you suggest as a workaround?

I've asked you to provide ipaserver-install.log in the bug. Without it
it is a bit hard to see how to help. Let's continue in the bug.
--
/ Alexander Bokovoy

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

[Freeipa-users] Password expiration after reset

[Giulio Casella]

Hi guys,
I'm trying to populate FreeIPA (4.2.3) using API, but after user 
creation (and password has been set) user must change password at first 
logon. Same beahviour after a password change by admin.


Although this behaviour is desirable in many situations, I can't afford 
it, I've got to import tens of thousands users, and I can't force them 
to change their password.

How can I bypass this password change?

And, by the way: is there a way to disable password expiration?


Thanks  in advance,
Giulio

--
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] Password expiration after reset

[Alexander Bokovoy]

On Wed, 16 Dec 2015, Giulio Casella wrote:

Hi guys,
I'm trying to populate FreeIPA (4.2.3) using API, but after user 
creation (and password has been set) user must change password at 
first logon. Same beahviour after a password change by admin.


Although this behaviour is desirable in many situations, I can't 
afford it, I've got to import tens of thousands users, and I can't 
force them to change their password.

How can I bypass this password change?

And, by the way: is there a way to disable password expiration?

http://www.freeipa.org/page/New_Passwords_Expired

If you are using API to create users and set their passwords, you can
use technique like described here:
https://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html

--
/ 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] Active Directory Sites and IPA-AD-Trust

[Sumit Bose]

On Wed, Dec 16, 2015 at 10:33:17AM +, wouter.hummel...@kpn.com wrote:
> Hi All,
> 
> While TCPdumping logins on an IPA client using an AD account I found out that 
> SSSD doesn't take AD Sites into account. I see a DNS lookup for 
> _kerberos._udp. and _kerberos._tcp. and then a Kerberos 
> attempt at one or more of the AD servers (both the local and non-local ones).
> 
> While this isn't a huge problem it does delay logins where communication with 
> the AD kdc is required.
> 
> Is there a way to get sssd to use the proper site for trusted AD domains?

I'm afraid currently there is no way for IPA clients.

If the SSSD client is directly joined to a AD domain, SSSD tries to
determine the site the client belongs to and prefers DC form this site
for all communications.

An IPA client gets all information from the IPA server (there is a
similar concept to sites in IPA but this is still wip). Only for
password authentication SSSD will directly connect to an AD DC.
Currently this happens completely inside libkrb5 which by default is
configured to do DNS SRV lookups to find a suitable DC (dns_lookup_kdc =
true in krb5.conf). Since libkrb5 is not aware fo sites it will just do
the plain _kerberos._udp. you see in the dump.

The only way to get around this would be to add a configuration section
for the ad.domain in krb5.conf and list suitable DC here. But this of
course has a number of drawbacks.

HTH

bye,
Sumit

> 
> 
> Met vriendelijke groet,
> 
> Wouter Hummelink
> Cloud Engineer
> [Description: Beschrijving: Beschrijving: cid:image003.gif@01CC7CE9.FCFEC140]
> KPN IT Solutions
> Platform Organisation Cloud Services
> Mail: wouter.hummel...@kpn.com
> Telefoon: +31 (0)6 1288 2447
> [cid:image002.png@01D0DA65.706AE4B0]
> P Save Paper - Do you really need to print this e-mail?
> *
> KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, 
> Handelsregister 52959597 Amsterdam
> The information transmitted is intended only for use by the addressee and may 
> contain confidential and/or privileged material.
> Any review, re-transmission, dissemination or other use of it, or the taking 
> of any action in reliance upon this information by persons
> and/or entities other than the intended recipient is prohibited. If you 
> received this in error, please inform the sender and/or addressee immediately
> and delete the material. Thank you.
> *
> 




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

Re: [Freeipa-users] freeipa-server-install fails to compare DNs in certificates

[Harald Dunkel]

On 12/16/2015 12:27 PM, Alexander Bokovoy wrote:

> I've asked you to provide ipaserver-install.log in the bug. Without it
> it is a bit hard to see how to help. Let's continue in the bug.

Bug report has been updated.


-- 
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] Active Directory Sites and IPA-AD-Trust

[wouter.hummelink]

Hi All,

While TCPdumping logins on an IPA client using an AD account I found out that 
SSSD doesn't take AD Sites into account. I see a DNS lookup for 
_kerberos._udp. and _kerberos._tcp. and then a Kerberos 
attempt at one or more of the AD servers (both the local and non-local ones).

While this isn't a huge problem it does delay logins where communication with 
the AD kdc is required.

Is there a way to get sssd to use the proper site for trusted AD domains?


Met vriendelijke groet,

Wouter Hummelink
Cloud Engineer
[Description: Beschrijving: Beschrijving: cid:image003.gif@01CC7CE9.FCFEC140]
KPN IT Solutions
Platform Organisation Cloud Services
Mail: wouter.hummel...@kpn.com
Telefoon: +31 (0)6 1288 2447
[cid:image002.png@01D0DA65.706AE4B0]
P Save Paper - Do you really need to print this e-mail?
*
KPN IT SOLUTIONS is de 'handelsnaam' voor KPN Corporate Market BV, 
Handelsregister 52959597 Amsterdam
The information transmitted is intended only for use by the addressee and may 
contain confidential and/or privileged material.
Any review, re-transmission, dissemination or other use of it, or the taking of 
any action in reliance upon this information by persons
and/or entities other than the intended recipient is prohibited. If you 
received this in error, please inform the sender and/or addressee immediately
and delete the material. Thank you.
*

-- 
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] Password expiration after reset

[Giulio Casella]

Il 16/12/2015 16:07, Alexander Bokovoy ha scritto:

On Wed, 16 Dec 2015, Giulio Casella wrote:

Hi guys,
I'm trying to populate FreeIPA (4.2.3) using API, but after user
creation (and password has been set) user must change password at
first logon. Same beahviour after a password change by admin.

Although this behaviour is desirable in many situations, I can't
afford it, I've got to import tens of thousands users, and I can't
force them to change their password.
How can I bypass this password change?

And, by the way: is there a way to disable password expiration?

http://www.freeipa.org/page/New_Passwords_Expired

If you are using API to create users and set their passwords, you can
use technique like described here:
https://www.redhat.com/archives/freeipa-users/2012-June/msg00360.html



Thank you for the info Alexander, I wasn't aware of the page
/ipa/session/change_password.

After creating a user via API in the usual way (json submission to 
/ipa/session/json) I can perform a password change submitting user 
credential to /ipa/session/change_password, thus resetting password 
expiration accordingly to system settings.


It works like a charme.

Thank you again,
Giulio.

--
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] AD group members

[Winfried de Heiden]

  
  
Hi all,
  
  Adding AD-users to an IPA external group seems to be problematic.
  However, adding AD-groups (with AD-users as members) to a IPA
  external groups seems to work well. Four group were created and
  all are shown.
  
  Smell a bit like a bug, does't it?
  
  Winny

Op 15-12-15 om 18:55 schreef Sumit
  Bose:


  On Tue, Dec 15, 2015 at 11:38:08AM -0500, Alexander Bokovoy wrote:

  


- Original Message -


  Hi,

If PAC is not being used using key, how is group membership determined?


By asking IPA master to give list of groups AD user belongs to.
The complexity of this process makes it hard to have full list of groups available in advance in all cases.
MS-PAC record in Kerberos ticket has its feature that AD DC will put the correct and full list of groups
the user is a member of at the time of issuing TGT, signed by the AD DC's signature. This means after validating
the ticket we can trust its content for caching. In case of no PAC data available we have to resort to less precise
methods that would give incomplete information for some of situations like incomplete GC content for multidomain
AD forests.



  Also: it feels like the Linux client is contacting AD to obtain a Kerberos
ticket and not the IPA-server. (for AD users). Is that true?


Yes, how would you imagine doing it differently? AD DCs are authoritative for their users, not IPA KDC.
This is basic feature of Kerberos protocol.

  
  
This is true for getting a TGT for the user, but when it comes to
authentication against an IPA client there is a step which involves the
IPA KDC as well. Either if you use Kerberos/GSSAPI authentication, e.g.
with ssh, or password authentication, in both cases a Kerberos service
ticket for the IPA client is needed which is issued by the IPA KDC and
here is were the SIDs for IPA group memberships are added.

In the ssh case the ssh client will ask the IPA KDC for the service
ticket by sending a valid TGT or cross-realm TGT in the trust case. In
the password authentication case SSSD will ask for the same service
ticket after getting a TGT for the user from the AD DC. This step is
called validation because SSSD needs a prove that the TGT was really
issued by a valid KDC. A user calling kinit can but pretty sure that the
KDC is valid because the password is a shared secret between the user
and the KDC in this case. A service like SSSD cannot be sure that the
user is not an attacker which spoofed e.g. DNS and let SSSD talk to a
invalid KDC which of course will issue TGTs for the attacker. To make
sure the ticket is valid SSSD uses the shared secret it has with the
valid KDC, the host keys in /etc/krb5.keytab, to validate the TGT by
requesting a service ticket for the host itself. If the service ticket
can be decrypt with the keys in the keytab SSSD can be pretty sure that
the service ticket and hence the TGT are valid.

Coming back to the original issue with the missing group. Can you share
the definition of the IPA external group and the related IPA POSIX group
for a group which is still present and one which got deleted. The output
of 'ipa group-show --all --raw group_name' should be sufficient for a
start. Feel free to send the output to me directly if it contains
sensitive data.

bye,
Sumit


  

With IPA 4.2 on systems like RHEL 7.2/CentOS 7.2/Fedora 23 you can configure MIT Kerberos to use MS-KKDC proxy provided by IPA.
In such case IPA masters can be used as Kerberos proxy but the actual authentication decision is done by AD DCs anyway.
-- 
/ 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] AD group members

[Sumit Bose]

On Wed, Dec 16, 2015 at 09:46:37AM +0100, Winfried de Heiden wrote:
> Hi all,
> 
> Adding AD-users to an IPA external group seems to be problematic. However,
> adding AD-groups (with AD-users as members) to a IPA external groups seems to
> work well. Four group were created and all are shown.

Thank you, this is a very useful information, I hope that I will be able to
reproduce the issue with this and the data you send me by private email.

bye,
Sumit

> 
> Smell a bit like a bug, does't it?
> 
> Winny

-- 
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] AD group members

[Winfried de Heiden]

  
  
Hi all,
  
  I changed the group names so the alpabetical order changes, no
  effect. However, sorting the corresponding SID's, the first SID
  belongs to the group always shown.
  
  Mmmm, only the first one is taken and the rest is thrown out...?
  
  Cheers!
  
  Winny

Op 16-12-15 om 10:01 schreef Sumit
  Bose:


  On Wed, Dec 16, 2015 at 09:46:37AM +0100, Winfried de Heiden wrote:

  
Hi all,

Adding AD-users to an IPA external group seems to be problematic. However,
adding AD-groups (with AD-users as members) to a IPA external groups seems to
work well. Four group were created and all are shown.

  
  
Thank you, this is a very useful information, I hope that I will be able to
reproduce the issue with this and the data you send me by private email.

bye,
Sumit


  

Smell a bit like a bug, does't it?

Winny

  


  


-- 
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] freeipa-server-install fails to compare DNs in certificates

[Harald Dunkel]

On 12/15/2015 04:04 PM, Alexander Bokovoy wrote:

> It makes possible others to see your specific details as this is the
> first time we get such bug report.

Done: https://bugzilla.redhat.com/show_bug.cgi?id=1292042

Now what would you suggest as a workaround?


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