Re: [Freeipa-users] Keycloak + FreeIPA New password expiry

[Brian Candler]

On 25/01/2017 13:48, Georgijs Radovs wrote:
Is it possible to configure FreeIPA server so it does not mark new 
passwords, set by Keycloak's LDAP bind user, expired?


Yes, you need to configure the privileged LDAP bind user in 
passSyncManagersDNs:


dn: cn=ipa_pwd_extop,cn=plugins,cn=config
passSyncManagersDNs: uid=

Note that this setting does not replicate - it needs to be applied to 
all replicas by hand.


See:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#password-sync
-- 
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] Not able to replicate user keys across master and client

[Brian Candler]

On 12/01/2017 10:59, hirofumi.morik...@accenture.com wrote:


Let me further clarify the question that is asked by Niraj below.

Currently, we have 1 master FreeIPA server and 1 client server. 
Evaluating your product for production deployment


Master and client connectivity is established and when creating the 
user in the web console, it is indeed creating the user in the client 
machine


However, When we add public key through the web console below, this 
key is not created(or transfered) to the client machine




That's correct: it doesn't copy them anywhere, nor is it supposed to.

Instead, the keys sit in the FreeIPA LDAP database. When you install the 
ipa-client package on a host, it configures sshd so it communicates via 
sssd to query the authorized keys in LDAP.  You will find:


# /etc/ssh/sshd_config
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys

# /etc/sssd/sssd.conf
[sssd]
services = nss, pam, ssh, sudo

That means you have central control of your authorized_keys with 
FreeIPA, without copying them onto every hosts' filesystem.


You also have central control of your user accounts, group memberships, 
uid and gid mappings, sudo policy, host access policy (i.e. which users 
are allowed to login to which hosts), ...  All this is done via sssd and 
LDAP as well.


HTH,

Brian.

-- 
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] Windows Server can't use FreeIPA's DNS server

[Brian Candler]

On 14/01/2017 20:01, Raul Dias wrote:


I am migrating a network to FreeIPA. LDAP, NFS, no Active Directory.

A Windows Server 2008 R2, cannot use FreeIPAs bind to resolve DNS query.
This server works fine with my old bind server, google's dns server 
(8.8.8.8), but not FreeIPA's.
Using wireshark, I can see the the response gets to this host, but is 
simply ignored.  Clocks are in sync.


Not sure if the problem is in the FreeIPA's side, probably not.

Any ideas?


On FreeIPA host:  tcpdump -i eth0 -nnv -s0 port 53 and host x.x.x.x

where x.x.x.x is IP address of the 2008R2 server, and assuming eth0 is 
the NIC.


See if any DNS queries arrive at the FreeIPA server. If no: then the 
problem is with the 2008R2 server, or the network in between. If yes: 
then see if FreeIPA is answering the queries or not.


-- 
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] Windows Server can't use FreeIPA's DNS server

[Brian Candler]

On 16/01/2017 00:52, Raul Dias wrote:

The  packets are getting back  That has being stablished already.


With Wireshark at the 2008R2 end?

I am looking for possible reasons it would disregard the answer, but 
accept when using a non-freeipa bind9 one.


Look at wireshark detail on both sets of responses; check for any 
differences including the flags. You're sure one of the servers isn't 
answering with a REFUSED answer for example? (That is, one of the bind 
servers might not allow queries from the source address of the 2008R2 
server)


Also compare the bind configs. For example, is DNSSEC enabled in one but 
not the other?


--
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] Windows Server can't use FreeIPA's DNS server

[Brian Candler]

On 16/01/2017 16:37, Raul Dias wrote:

Did some testing.

From the windows server, did a port scanner on the IPA server (tcp + 
udp), no blocking between. (tested open).


The IPA has DNSSEC on, but that is for the zones only, right? There is 
no indication of DNSSEC in the datagrams.


You can have a DNSSEC-validating resolver (cache), but you're right 
you'd see things in the packet (EDNS).



The wireshark in the windows server:

Looks like a perfectly good DNS response to me.  Windows is a strange 
beast :-(


Horrible workaround: if you can find a DNS server which Windows likes, 
you can configure that DNS server to forward all the IPA-hosted zones to 
the IPA server.


--
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 domains and sub-domains

[Brian Candler]

On 27/10/2016 09:30, Alexander Bokovoy wrote:

Yes, you can do that, there is no issue at all.


Thank you for confirming that.

To the OP: in that case, I'd still recommend that you choose a distinct 
kerberos realm like IPA.YOURCOMPANY.COM, with associated primary domain 
"ipa.yourcompany.com", and let FreeIPA manage that domain so that it 
sets up all the right SRV records for auto-discovery.  But you don't 
need to put any hosts inside that DNS domain at all.


This gives you the flexibility to set up future Kerberos realms like 
AD.YOURCOMPANY.COM if you deploy Active Directory or Samba4 later.


Regards,

Brian.

--
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 domains and sub-domains

[Brian Candler]

On 27/10/2016 10:07, Brian Candler wrote:
To the OP: in that case, I'd still recommend that you choose a 
distinct kerberos realm like IPA.YOURCOMPANY.COM, with associated 
primary domain "ipa.yourcompany.com", and let FreeIPA manage that 
domain so that it sets up all the right SRV records for 
auto-discovery.  But you don't need to put any hosts inside that DNS 
domain at all. 


Aside: I have just been trying this out.

What's slightly confusing is that the ipa server-install process 
requires you to set a "domain name" as well as a realm, and it's not 
clear to me which "domain" to put here. Is this the domain which 
corresponds to the realm, or the domain which the clients normally 
reside in, or something else?


For example, suppose I have realm IPA.MYCOMPANY.COM but my servers are 
xxx.int.mycompany.com.  Should I set the FreeIPA "domain" to 
ipa.mycompany.com or int.mycompany.com, or mycompany.com ?


After some experimentation, it seems that the LDAP baseDN is always 
taken from the realm (dc=ipa,dc=mycompany,dc=com). But the DNS domain is 
used for:


- nisDomain and associatedDomain
- ipaDefaultEmailDomain
- crucially, the SRV records are published under the DNS domain

So it looks like really you should put "ipa.mycompany.com" as the DNS 
domain, even if the IPA servers are in a different domain.


Regards,

Brian.

--
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] system to pick up pa user-mod --uid change - how long?

[Brian Candler]

On 08/11/2016 13:57, lejeczek wrote:
I've changed an uid of a.user but system: $ id a.user - still shows 
old id.
When is the system supposed to notice that change? 


You might want to force the cache to expire early. Try:

sss_cache -U

or

sss_cache -u 

(I'm afraid I don't know what the automatic expiry time is)

--
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] FreeIPA as domain controller?

[Brian Candler]

Sorry if this is a frequently asked question, but it's not easy to find 
a simple answer.


* Can I use FreeIPA (v4) as a domain controller for Windows machines to 
join?


* If not, what's the recommended free/open solution? Would it be to set 
up a Samba4 domain controller, and then set up cross-realm trust between 
FreeIPA and Samba4?


(That is: assuming I want central AAA for both Linux boxes and Windows 
boxes)


Things I found:

* http://www.freeipa.org/page/About

... but it only mentions FreeIPA v2 and v3

* 
https://sambaxp.org/archive_data/SambaXP2016-SLIDES/thu/track2/sambaxp2016-thu-track2-Alexander_Bokovoy-Andreas_Schneider-SambaAndFreeIPAAnUpdateOnActiveDirectoryIntegration.pdf


... report on work-in-progress. It does say:

" FreeIPA Domain Controller is unlike Samba AD → Windows cannot be 
joined to FreeIPA".  But it's not clear if this is an eventual goal, or 
whether it's likely to remain this way.


I guess keeping a lot of MS-specific nonsense out of FreeIPA is a good 
thing :-)


Thanks,

Brian.


--
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 as domain controller?

[Brian Candler]

On 17/10/2016 15:52, Alexander Bokovoy wrote:

If you set ID range for corresponding AD domain in IPA to be
'ipa-ad-trust-posix' and make sure all users that need to logon to IPA
have POSIX attributes, then it should work.

I think most of this is described in the Windows Integration Guide for
RHEL7.


Thank you.

Final question. Suppose I use just the ipa-client package with sssd-ad 
pointing to Samba4 (or even real Windows AD). Is that likely to be a 
satisfactory solution for managing the *nix boxes, or would I be better 
of with two separate domains?


For example, would I lose the features that FreeIPA gives me like 
host-based access controls, sudo controls, central storage of ssh public 
keys?


Thanks,

Brian.

--
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

On 25/10/2016 10:50, Prasun Gera wrote:
When is principal expiration triggered ? I haven't set it explicitly 
for any user, and ipa user-show doesn't show that attribute either. 
I'm not very familiar with kerberos. 

It doesn't show it unless it has been set. You can set it like this:

# ipa help user-mod
...
  --principal-expiration=DATETIME
Kerberos principal expiration

(This is from IPA under CentOS 7. Older versions might not have this 
feature at all).


And as you and David said earlier, if the principal expires, kinit 
shouldn't work either, right ?


Yes I agree. I have just tried setting krbPasswordExpiration to a very 
old time, using ldapmodify.


# ldapmodify -D 'cn=Directory Manager' -W
Enter LDAP Password:
dn: uid=bcandler,cn=users,cn=accounts,dc=ipa,dc=example,dc=com
changetype: modify
replace: krbPasswordExpiration
krbPasswordExpiration: 2001010100Z
-

^D

But this works for me:

$ sudo -s

[sudo] password for bcandler:
Password expired. Change your password now.
sudo: Account or password is expired, reset your password and try again
Current Password:
New password:
Retype new password:

#


But actually, I didn't try the web UI with an expired password yet. I'll 
try that later.


Regards,

Brian.

--
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

On 25/10/2016 08:29, David Kupka wrote:
If I understood Brian correctly he was asking about expiration of NTLM 
password hashes.


Partly.

As long as the hash remains in the database and is readable via LDAP, I 
know it will continue to work for authentication.  However I was also 
asking whether a long-expired password would prevent a user from logging 
into the webUI or obtaining a kerberos ticket.


Scenario is: a user who is mostly wireless-only, who very rarely uses 
IPA for anything else. Their password expires, and they never notice 
because it keeps working. However, (say) a year later, they decide to 
login to IPA for some reason - maybe because they've decided it's time 
to change their wireless password.  Will their old expired password 
still be usable for this?  I'm hoping it would simply tell them that the 
account has expired and force a password change.


Aside: I realise there are other ways I can handle this. Perhaps I 
*should* make passwords expire for wireless too, by checking the 
krbPasswordExpiration field in the RADIUS server. But then I need some 
way to warn people that their passwords are about to expire and give 
them an opportunity to change it - e.g. by mailing out a warning a 
couple of weeks before it does.


Regards,

Brian.

--
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

On 25/10/2016 00:02, Prasun Gera wrote:
I've seen some different behaviour. I've had errors for users 
(including the admin user) trying to log in with possibly an expired 
password. Both webui and ssh would fail, but kinit would work. I'm not 
sure if this is related to the password's expiration or the account's 
expiration. My /var/log/secure has messages like "pam_sss(sshd:auth): 
received for user uname: 13 (User account has expired)". Is there a 
setting for default expiration of user accounts ? I don't remember 
setting it anywhere.


By "account expiration" do you mean the "--principal-expiration" option 
to ipa user-xxx? Or is there another setting?


Code 13 is PAM_ACCT_EXPIRED, at least in the "new" constants

$ egrep '\b13\b' /usr/include/security/*pam*
/usr/include/security/_pam_compat.h:# define PAM_USER_UNKNOWN 13
/usr/include/security/_pam_types.h:#define PAM_ACCT_EXPIRED 13/* 
User account has expired */
/usr/include/security/_pam_types.h:#define PAM_AUTHTOK_TYPE   13 /* The 
type for pam_get_authtok */


This to me implies it's not looking at the krbPasswordExpiration 
attribute, because it could (or should) use PAM_AUTHTOK_EXPIRED (27) for 
that instead.


For me, pam_sss seems to handle expiry correctly. For example if I reset 
an account password (which in turn causes it to expire immediately), and 
then someone logs in their ssh private key, and subsequently does 
"sudo", sudo prompts them for the password, tells them it has expired, 
but gives them the opportunity to change it.


However it's not impossible that the PAM module has some buried logic, 
e.g. it refuses to use a password which expired more than X days ago. 
That was the reason for my original question.  I guess I should try 
setting some expiry date way in the past.


The other thing is to look in the source code for pam_sss to see under 
which conditions it returns PAM_ACCT_EXPIRED.  The answer is: when it 
gets ERR_ACCOUNT_EXPIRED from parse_krb5_child_response. Which in turn 
is when we get KRB5KDC_ERR_NAME_EXP from Kerberos. Which in turn is 
"Client's entry in database has expired".


http://web.mit.edu/kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Kerberos-V5-Library-Error-Codes.html

But as has already been said - if the *principal* has expired you 
shouldn't be able to login with kinit at all.


Regards,

Brian.

-- 
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

Looking in MIT krb5 source:

$ grep -R ERR_NAME_EXP .
./src/include/k5-int.h:#define KDC_ERR_NAME_EXP1 /* 
Client's entry in DB expired */

./src/kdc/kdc_util.c:return(KDC_ERR_NAME_EXP);
./src/lib/krb5/error_tables/krb5_err.et:error_code 
KRB5KDC_ERR_NAME_EXP,"Client's entry in database has expired"


There appears to be only one case where NAME_EXP is returned: when the 
client.expiration field is passed (not client.pw_expiration)


The fields are defined in krb5_db_entry in src/include/kdb.h:

krb5_timestampexpiration;   /* When the client 
expires */
krb5_timestamppw_expiration;/* When its passwd 
expires */


I think "expiration" must equate to the "principal expiration" in IPA. 
But only regular password expiry would give you the option of changing it.


Regards,

Brian.

=== from src/kdc/kdc_util. c ===

/* The client must not be expired */
if (client.expiration && client.expiration < kdc_time) {
*status = "CLIENT EXPIRED";
if (vague_errors)
return(KRB_ERR_GENERIC);
else
return(KDC_ERR_NAME_EXP);
}

/* The client's password must not be expired, unless the server is
   a KRB5_KDC_PWCHANGE_SERVICE. */
if (client.pw_expiration && client.pw_expiration < kdc_time &&
!isflagset(server.attributes, KRB5_KDB_PWCHANGE_SERVICE)) {
*status = "CLIENT KEY EXPIRED";
if (vague_errors)
return(KRB_ERR_GENERIC);
else
return(KDC_ERR_KEY_EXP);
}

--
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] Do expired passwords remain usable indefinitely?

[Brian Candler]

Question: when a password expires, does it remain in a usable state in 
the database indefinitely? For example, if someone comes along a year 
after their password has expired, can they still login once with that 
password?


This is actually what I want, but I just want to confirm there's not 
some sort of secondary threshold which means that an expired password is 
not usable X days after it has expired.  Or, if there is such a 
secondary threshold, where I can find it.


The scenario is a RADIUS server for wifi which reads NTLM password 
hashes out of the database to authenticate - this continues to work 
after expiry. However I want users to be able to do a self-reset later 
if and when they want to.


Thanks,

Brian.

--
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] Disabling Anonymous Binds (LDAP)

[Brian Candler]

On 16/11/2016 16:46, dan.finkelst...@high5games.com wrote:
I've seen some discussion in the (distant) past about disabling 
anonymous binds to the LDAP component of IPA, and I'm wondering if 
there's a preferred method to do it. Further, are there any known 
problems with disabling anonymous binds when using FreeIPA? The only 
modern documentation I can find is here: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, 
and I'm curious if FreeIPA has a different way.


FWIW, I see the same here. Installed ipa-server under CentOS 7 (which 
gave me freeipa 4.2.0), and found anonymous binds allowed: tested by 
"ldapsearch -x ..."


I was able to disable anonymous bind (and also disable unencrypted 
queries) by changing the cn=config entry:


|dn: cn=config|
|changetype: modify|
|replace: nsslapd-allow-anonymous-access|
|nsslapd-allow-anonymous-access: rootdse|
|-|
|replace: nsslapd-minssf|
|nsslapd-minssf: 56|

I don't think this replicated from master to slave though, and I ended 
up doing it on slaves as well.


If there is an "official" way to disable anon bind on FreeIPA 4.x, I 
would like to know it.


Thanks,

Brian.
-- 
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] LDAP bind permitted for expired passwords

[Brian Candler]

Looking at FreeIPA 4.2 under CentOS 7: I find that LDAP simple binds 
succeed even for DNs whose krbPasswordExpiration time has passed. Is 
this fixed, or is it possible to change this?


The reason I ask is because some applications use LDAP bind as a 
password validation oracle: for example, if you configure a Sophos UTM 
to use LDAP, it works this way.


I realise that an LDAP bind doesn't give a way to prompt the user to 
change their password. However, a failure could be used to force the 
user to go to the web UI to reset it (and you could always notify people 
by E-mail if their password is about to expire)


Thanks,

Brian.

--
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] mkhomedir difference between ipa master and ipa replica

[Brian Candler]

On 04/11/2016 12:20, Petr Vobornik wrote:

You can check with what options authconfig was called by:
  # cat /var/log/ipaclient-install.log | grep authconfig

if  --enablemkhomedir is not there then it is possible that something
else enabled it.


It's not there:

$ sudo cat /var/log/ipaclient-install.log | grep authconfig
[sudo] password for brian.candler:
2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' 
'--enablesssdauth' '--update' '--enablesssd'
2016-10-27T15:30:44Z DEBUG args='/usr/sbin/authconfig' '--update' 
'--nisdomain' 'ipa.example.com'


And:

$ sudo cat /var/log/ipaclient-install.log | grep mkhome
2016-10-27T15:30:38Z DEBUG /usr/sbin/ipa-client-install was invoked with 
options: {'domain': 'ipa.example.com', 'force': False, 
'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox': 
False, 'primary': False, 'realm_name': 'IPA.EXAMPLE.COM', 'force_ntpd': 
False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 
'on_master': True, 'no_nisdomain': False, 'nisdomain': None, 
'ca_cert_file': None, 'principal': None, 'keytab': None, 'hostname': 
'ipa-1.int.example.com', 'request_cert': False, 'trust_sshfp': False, 
'no_ac': False, 'unattended': True, 'all_ip_addresses': False, 
'location': None, 'sssd': True, 'ntp_servers': None, 'kinit_attempts': 
5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 
'force_join': False, 'firefox_dir': None, 'server': 
['ipa-1.int.example.com'], 'prompt_password': False, 'permit': False, 
'debug': False, 'preserve_sssd': False, 'mkhomedir': False, 'uninstall': 
False}


This server has been through several iterations of ipa-server-install / 
ipa-server-uninstall. It is possible that one of the earlier 
incantations was done with --mkhomedir, since I didn't do the first one.


Next time I do a fresh, clean IPA install I will check the PAM 
configuration. (Although in that case, perhaps ipa-server-uninstall is 
not cleaning up fully after itself?)


Regards,

Brian.

--
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] mkhomedir difference between ipa master and ipa replica

[Brian Candler]

I have set up freeipa using CentOS 7 and the default 4.2.0 packages.

I found that on the master, the user's home directory is created 
automatically, but on the replicas it is not. Looking into the contents 
of /etc/pam.d, the following files are different:


fingerprint-auth-ac

password-auth-ac

smartcard-auth-ac

system-auth-ac

(two examples below). The replicas don't have the line which invokes 
pam_oddjob_mkhomedir.so


I notice that both ipa-server-install and ipa-replica-install have the 
following option:


--mkhomedir create home directories for users on their 
first login


but I did not supply this option in either case. I believe the actual 
options I gave were:


ipa-server-install --setup-dns
ipa-replica-install --setup-ca --setup-dns --forwarder x.x.x.x 
/var/lib/ipa/replica-info-*.gpg


respectively.  Is this expected behaviour, or should I raise a ticket?

Thanks,

Brian Candler.

--- fingerprint-auth-ac2016-11-04 11:23:08.0 +
+++ fingerprint-auth-ac.replica2016-11-04 11:23:19.0 +
@@ -16,7 +16,6 @@
 session optional  pam_keyinit.so revoke
 session required  pam_limits.so
 -session optional  pam_systemd.so
-session optional  pam_oddjob_mkhomedir.so umask=0022 skel=/etc/skel
 session [success=1 default=ignore] pam_succeed_if.so service in 
crond quiet use_uid

 session required  pam_unix.so
 session optional  pam_sss.so

--- system-auth-ac2016-11-04 11:24:13.0 +
+++ system-auth-ac.replica2016-11-04 11:24:26.0 +
@@ -22,7 +22,6 @@
 session optional  pam_keyinit.so revoke
 session required  pam_limits.so
 -session optional  pam_systemd.so
-session optional  pam_oddjob_mkhomedir.so umask=0022 skel=/etc/skel
 session [success=1 default=ignore] pam_succeed_if.so service in 
crond quiet use_uid

 session required  pam_unix.so
 session optional  pam_sss.so

-- 
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] mkhomedir difference between ipa master and ipa replica

[Brian Candler]

On 04/11/2016 11:32, Brian Candler wrote:


I notice that both ipa-server-install and ipa-replica-install have the 
following option:


--mkhomedir create home directories for users on their 
first login


but I did not supply this option in either case. I believe the actual 
options I gave were:


ipa-server-install --setup-dns
ipa-replica-install --setup-ca --setup-dns --forwarder x.x.x.x 
/var/lib/ipa/replica-info-*.gpg


respectively.  Is this expected behaviour, or should I raise a ticket?

Supplementary note for the benefit of the list: I tried manually 
updating the replica machines' PAM configurations to match, but I then 
got this error


org.freedesktop.DBus.Error.ServiceUnknown: The name 
com.redhat.oddjob_mkhomedir was not provided by any .service files

Last login: Fri Nov  4 11:36:07 2016 from x.x.x.x
Could not chdir to home directory /home/brian.candler: No such file or 
directory


All the machines had the same packages installed, including the 
"oddjob-mkhomedir" package. But the slaves were missing a single 
symlink. Solution was:


ln -s /usr/lib/systemd/system/oddjobd.service 
/etc/systemd/system/multi-user.target.wants/oddjobd.service


Regards,

Brian.
-- 
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 as domain controller?

[Brian Candler]

On 17/10/2016 15:06, Alexander Bokovoy wrote:
Would there be any benefit the other way round - creating identities 
in S4 and using them to login to FreeIPA-joined *nix boxes? I guess 
the problem then is where posix attributes like uid and gid come from.

This works for Samba AD > 4.4. The code in Samba that supports forest
trust is a bit new (and was written by Red Hat's request) so depending
on what version you are using your experience will vary.

IPA supports different methods for mapping IDs, including algorithmic
ones. We default to algorithmic ID range if existing POSIX IDs aren't
found.

See ID MAPPING section in sssd-ad man page for details. You don't need
to configure anything in SSSD, though, because it is done automatically
based on the ID ranges in IPA. 


OK, but let me just see if I can clarify. Given the following scenario:

SAMBA . . . . . . FREEIPA
  |  |
USER   SERVER

The server isn't joined directly to the Samba domain, but the manpage 
for sssd-ad says "This provider requires that the machine be joined to 
the AD domain".


So is it true that:

1. The server is not configured to use sssd-ad? Does it automatically 
use this module if, because of trust relationships, a user from the 
Samba domain logs into it? Would it need configuration, or does it pick 
up everything it needs from the DNS?


2. If I create the posix uids/gids as extra attributes in the Samba 
domain, the algorithmic ID mapping isn't required?


Thanks,

Brian.

-- 
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] Best and Secure Way for a System Account

[Brian Candler]

On 17/10/2016 14:56, freeipa-users-requ...@redhat.com wrote:

But now I have to create for this user a ACI to read the uid,
passwd,mail,mailAlternateAddress...

mailAlternateAddress is in "objectClass mailrecipient"

I mean I must have a ACI like
access to attribute= 

Have any a hint or link to understand this Problem?


I found this guide very helpful, specifically for allowing access to a 
NT password hash attribute for doing wireless authentication.


http://firstyear.id.au/blog/html/2015/07/06/FreeIPA:_Giving_permissions_to_service_accounts..html

They are doing it the correct way here: by creating a service principal 
for the RADIUS server, which it uses to get a kerberos ticket and 
authenticate itself to the directory.  But you could also use similar 
steps to apply those permissions to a regular user.


And the related guide if you're interested:

http://firstyear.id.au/blog/html/2016/01/13/FreeRADIUS:_Using_mschapv2_with_freeipa.html

Regards,

Brian.

--
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 as domain controller?

[Brian Candler]

On 17/10/2016 11:14, Alexander Bokovoy wrote:

We are not yet at the point you could use IPA-hosted identities to login
to Windows machines joined to AD, though, regardless which AD
implementation it is.

That's very helpful, thank you. So basically it means that for the time 
being, our admins will need two identities (one in each realm) and there 
is not much benefit in setting up cross-realm trust.


Would there be any benefit the other way round - creating identities in 
S4 and using them to login to FreeIPA-joined *nix boxes? I guess the 
problem then is where posix attributes like uid and gid come from.


Regards,

Brian.

--
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] Removing DNS component

[Brian Candler]

FreeIPA (4.2.0) was installed with the DNS component enabled, but I want 
to pull this out. Is it possible to remove it and clean up the records 
which were already there?


e.g. is it sufficient just to delete everything under 
cn=dns,dc=example,dc=com ?  I notice there are bunch of permissions 
entries in other parts of the tree which reference these with 
ipaPermTarget, do they have to go too?


Or would I have to re-install from scratch?

Thanks,

Brian.

--
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] Removing DNS component

[Brian Candler]

On 08/12/2016 17:05, Martin Basti wrote:
I suggest to keep DNS tree there and all permissions, just remove all 
zones using IPA API and disable DNS service and dnssyncd service in 
LDAP, because removing DNS completely is unsupported and untested


dn: cn=DNS,cn=vm-028.ipa.test,cn=masters,cn=ipa,cn=etc,$SUFFIX
objectClass: ipaConfigObject
objectClass: nsContainer
objectClass: top
ipaConfigString: startOrder 30
ipaConfigString: enabledService <--- remove this
cn: DNS


dn: cn=DNSKeySync,cn=vm-028.ipa.test,cn=masters,cn=ipa,$SUFFIX
objectClass: nsContainer
objectClass: top
ipaConfigString: dnssecVersion 1
ipaConfigString: startOrder 110
ipaConfigString: enabledService < remove this
cn: DNSKeySync

It will keep ipa dns* command working but without any effect



That did the job - nothing listening on port 53 now. Thank you!

Regards,

Brian.

--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 08/12/2016 08:50, Pieter Nagel wrote:


Concrete scenario, I wonder if this will work:

A greenfields deployment, no other kerberos, no Active Directory. 
Internal DNS to be int.lautus.net  and FreeIPA 
manages that DNS domain and adds internal hosts to it as they enroll. 
Public-facing servers are manually registered in lautus.net 
 DNS which is hosted elsewhere. But FreeIPA is 
installed with realm LAUTUS.NET  so it adds 
_kerberos entries for realm LAUTUS.NET  to 
int.lautus.net , and I manually copy those 
entries to lautus.net , so everone agrees that they 
belong to the same realm.


The reason I want the realm to be LAUTUS.NET  is 
because it makes more sense to me that the internal desktops in the 
subdomain int.lautus.net  to enroll into a 
realm related to the parent DNS domain
I see a red flag with "desktops". Do you mean Windows desktops? Then you 
are talking Active Directory (or the Samba implementation of AD) and 
there are very specific rules for how the hostnames and the realms interact.


If you are talking Linux/BSD desktops, then it doesn't matter. 
Personally I would do it the other way round than you propose: let 
machines foo.lautus.net and bar.int.lautus.net use IPA.LAUTUS.NET as 
their kerberos realm, because this gives you the *option* of adding a 
distinct kerberos realm like AD.LAUTUS.NET later.


If you ever introduce Active Directory into your network then you don't 
want it to be either a subdomain or a parent domain of your IPA domain, 
unless you enjoy pain.


Changing your IPA realm later is also extremely painful.

, than it makes sense for the public-facing servers in the parent 
lautus.net  domain enroll into a realm related to 
an internal DNS subdomain.

It's not really a problem. In the DNS you create TXT records:

_kerberos.lautus.net.  TXT  "IPA.LAUTUS.NET"
_kerberos.int.lautus.net  TXT  "IPA.LAUTUS.NET"

and the auto-mapping of hosts to realms just works (in the *nix world 
anyway)


Personally I would have no problem publishing
_kerberos.lautus.net.  TXT  "IPA.LAUTUS.NET"
in the public DNS. It's up to you whether you put *.ipa.lautus.net and 
*.int.lautus.net in the public DNS.


Or am I making an issue of a cosmetic triviality, and it is not all 
all strange in the kerberos realm to enroll a server into a realm 
related to a DNS subdomain it is not part of?



In my opinion, not at all strange. You have three things:

1. The DNS domain of the host
2. The Kerberos realm that the host is in
3. The DNS domain of the Kerberos realm

2+3 are bound together, but 1 does not need to relate to 2+3 (unless you 
are Microsoft)


Regards,

Brian.
-- 
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] ipa fails to start after centos 7.3 upgrade

[Brian Candler]

On 12/12/2016 19:53, Rob Verduijn wrote:

I've recently upgraded to centos 7.3.
Didn't intend to so soon but should have checked the anounce lists 
before launching my ansible update playbook.


Most of my servers came through, and mostly also the ipa server.
There were duplicate rpms and a failed rpm upgrade.
After some yum magic the rpm duplicates where gone and all the updates 
installed.


Manually running ipa-server-upgrade also seems to finish properly.

However
ipactl start keeps failing on the ntpd service.
Not a big surprise since its running chronyd.

I now start the ipa server with 'ipactl start --ignore-service-failure'

Is there a way to explain the script that it should check for chronyd 
instead of ntpd ?



Aside: I also have a use case for running without ntp.  I run freeipa 
inside an lxd container (*), so ntpd is running on the outer host, not 
in the container.


However unlike you, after upgrading to CentOS 7.3 / FreeIPA 4.4.0 inside 
the container I don't see any problem:


[root@ipa-2 ~]# ipactl stop
Stopping ipa-otpd Service
Stopping pki-tomcatd Service
Stopping ntpd Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping ipa_memcached Service
Stopping kadmin Service
Stopping krb5kdc Service
Stopping Directory Service
ipa: INFO: The ipactl command was successful
[root@ipa-2 ~]# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting ipa_memcached Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting ipa-otpd Service
ipa: INFO: The ipactl command was successful
[root@ipa-2 ~]#

ntpd won't run inside the container, which is expected:

[root@ipa-2 ~]# systemctl status ntpd
● ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-12-14 10:51:09 
UTC; 2min 18s ago
  Process: 1357 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS 
(code=exited, status=0/SUCCESS)

 Main PID: 1358 (code=exited, status=255)

Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 4 
eth0:1 10.0.0.149 UDP 123
Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 5 
lo ::1 UDP 123
Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 6 
eth0 fe80::216:3eff:fef2:a083 UDP 123
Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listening on routing 
socket on fd #23 for interface updates

Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c016 06 restart
Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c012 02 
freq_set ntpd 0.000 PPM
Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c011 01 
freq_not_set
Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: ntpd.service: main 
process exited, code=exited, status=255/n/a
Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: Unit ntpd.service 
entered failed state.

Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: ntpd.service failed.

But ipactl is not complaining, which is good. But I don't know why it 
works for me and not for you.


Anyway, I hope that for future reference this use case remains 
supported.  In a container environment like lxd or docker, you *cannot* 
run ntpd (but that doesn't mean the time isn't synced!)


Regards,

Brian.

(*) Aside: this makes snapshotting IPA a breeze.


--
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] Kerberos realm for different domain

[Brian Candler]

On Sun, Dec 11, 2016 at 11:31 PM, David Kupka > wrote:



yes you can do it. DNS domain and Kerberos realm are two different
things. It's common and AFAIK recommended to capitalize DNS domain
to get the realm but it's not required.
If you really want to have them different make sure:
a) anotherdomain.com  is under your
control,
b) you don't already have other Kerberos instance (FreeIPA, MIT
KRB5, MS AD, ...) with ANOTHERDOMAIN.COM
 realm deployed.

With FreeIPA you can run
# ipa-server-install --domain example.com
 --realm ANOTHERDOMAIN.COM


But before you do, why do you want to have the realm different
from the domain?




Question: what "domain" does the --domain option to ipa-server-install 
actually refer to?


The man page just says " Your DNS domain name". But what does it 
actually alter?


1. the DNS domain which holds the kerberos realm location information? I 
don't think so; I think if you are searching for realm FOO.COM you'll 
always look in the DNS under "foo.com", that's a fixed relationship.


2. the DNS name of the IPA server itself? But if set up correctly, it 
already has an FQDN (as reported by "hostname -f"). And if you give the 
"--hostname" option, that's a FQDN not a bare hostname.


3. the DNS zone which IPA is authoritative for? But you can run IPA 
without integrated DNS.


4. the LDAP base DN? I guess that could be it: e.g. "--domain foo.com" 
puts everything under tree "dc=foo,dc=com"?


5. something else?

Thanks,

Brian.
-- 
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] Kerberos realm for different domain

[Brian Candler]

On 16/12/2016 08:21, Alexander Bokovoy wrote:


So you can have IPA masters with FQDNs in totally different DNS domains
than dictated by their Kerberos realm and --domain options.


That I understand - not only can the IPA masters have FQDNs in different 
DNS domains, but indeed the member machines of that realm as well.


What was unclear to me was whether "ipa-server-install --domain xxx" 
affects the content of the database being built (and therefore 
replicated later to the slaves), or is just something local to the host 
itself.


In the manpage for "ipa-client-install" it's much clearer: in that case, 
it says that --domain is the starting domain for LDAP server auto-discovery.


To clarify, there are several DNS auto-discovery mechanisms. Two of them 
are described in the MIT docs at

https://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Using-DNS

(1) Map hostname aaa.bbb.ccc to realm xxx.yyy.zzz

Look for TXT records for _kerberos.aaa.bbb.ccc, _kerberos.bbb.ccc, 
_kerberos.ccc. The TXT record gives the realm that this host belongs to.


(2) Realm xxx.yyy.zzz to Kerberos servers for that realm

Given realm xxx.yyy.zzz, look for in the DNS for SRV records for
_kerberos._udp.xxx.yyy.zzz
_kerberos-master._udp.xxx.yyy.zzz
_kpasswd._udp.xxx.yyy.zzz

This is all very clear.

Now, the manpage for ipa-client-install describes another one, which is 
where I get a bit fuzzy:


(3)

   DNS Autodiscovery
   Client installer by default tries to search for 
_ldap._tcp.DOMAIN  DNS
   SRV  records for all domains that are parent to its hostname. 
For exam-
   ple, if a client machine has a hostname 
'client1.lab.example.com',  the
   installer   will   try   to   retrieve  an  IPA  server 
hostname  from
   _ldap._tcp.lab.example.com, _ldap._tcp.example.com  and 
_ldap._tcp.com
   DNS  SRV  records,  respectively. The discovered domain is then 
used to
   configure client components (e.g. SSSD and Kerberos 5 
configuration) on

   the machine.

What it doesn't actually say (but I believe must be true) is that what 
it calls the "discovered domain" is in fact the *realm* to use.  If so, 
effectively this is algorithm (2) in reverse: instead of using it for 
realm to SRV mapping, you hunt for a domain which contains the right SRV 
records and use this to infer your realm.


Is that right?

(Is this a mechanism modelled on Active Directory? Otherwise, I would 
have thought you could use MIT algorithm (1) to discover your realm)




After all, these are *flexibility* options. They are not supposed to
make sense in all combinations. Where they aren't making sense, you are
allowed to shoot yourself in your feet if you know what you are doing.


Absolutely, and I don't want to get this wrong and have to start again :-)

OK, I have a final question on the planning of realms and DNS.

As we've already said, in an IPA-only installation, the machines which 
are members of the realms can happily have hostnames which are unrelated 
to the realm name: e.g.


 IPA.EXAMPLE.COM
 | | |
machines .foo.com
machines .bar.com

A user in IPA.EXAMPLE.COM can login to host .foo.com, either 
because their krb5.conf has a static domain->realm mapping, or there's a 
DNS entry: _kerberos.foo.com TXT "IPA.EXAMPLE.COM"


However, suppose I plan to end up with a trust to an Active Directory / 
Samba4 realm:


AD.EXAMPLE.COM <--trust--> IPA.EXAMPLE.COM
| | |  | | |
usersmachines

I want to allow users in the AD.EXAMPLE.COM realm to login to machines 
in the IPA.EXAMPLE.COM realm.


Will this still work when the machines are in different DNS domains? Or 
at this point, am I forced to give all the machines hostnames of the 
form .ipa.example.com ?


If the latter is true, it would be wise for me to start naming my hosts 
.ipa.example.com in the first place.


Thanks,

Brian.

--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 07/12/2016 08:58, freeIPA users list wrote:
On ke, 07 joulu 2016, List dedicated to discussions about use, 
configuration and deployment of the IPA server. wrote:
I know the Quick Start Guide and Deployment Recommendations cover 
this in

depth, but there are still some ambiguities.

I'm trying to figure out if a company like us, lautus.net should use 
a DNS

subdomain like ipa.lautus.net for the IPA domain, or not.

It is really depending on your deployment details.

If you already have some other Kerberized environment in place and you
are not going to replace it by FreeIPA, then you need to make sure that
new FreeIPA deployment would not conflict with the existing one.
Or if you think there's a chance you might want to add another 
Kerberized environment later (e.g. "ad.lautus.net")





should continue to be hosted by DNS servers elsewhere that delegate say,
ipa.lautus.net to FreeIPA.
The question of whether you host ipa.lautus.net DNS (or indeed 
lautus.net DNS) in FreeIPA is a different issue.


If you're happy with your existing DNS infrastructure, then you can 
either delegate ipa.lautus.net to your FreeIPA servers (with NS 
records); or run FreeIPA without DNS, and simply import the 
ipa.lautus.net SRV records directly into the lautus.net domain.


Having FreeIPA host the ipa.lautus.net domain means these SRV records 
are populated automatically, but it's not really that hard to add them 
to an existing DNS service.


OTOH, if you *don't* already have a good authoritative internal DNS 
service with a UI that you like, then you might want to use FreeIPA for 
this anyway. You can easily create extra zones in FreeIPA.


I would be a bit wary about putting FreeIPA servers out on the public 
Internet though. For one thing, the default config is an open resolver 
(which you can tighten easily enough). I also have a deep distrust of 
Java, but maybe that's just me.






But on the other hand the same doc is full of examples where a Kerberos
realm like EXAMPLE.COM (instead of IPA.EXAMPLE.COM) is used, i.e example
2.2. of secion 2.3.4. But the same guide also says that the Kerberos 
realm
should be the same as the ipa DNS domain, just uppercased. So example 
2.2.

implies that example.com is running their DNS domain on FreeIPA, for
everything, not just for IPA SRV and TXT entries.
The Kerberos realm always has a corresponding DNS domain, so realm 
IPA.LAUTUS.NET has a corresponding DNS domain "ipa.lautus.net".


But with FreeIPA you can still manage hosts called foo.lautus.net or 
bar.int.lautus.net. At worst you'd have some extra [domain_realm] 
mappings in krb5.conf


(Aside: Active Directory is much more fussy, and basically doesn't work 
if the hosts don't have hostnames within the same DNS domain as their 
kerberos realm - and indeed have reverse DNS as well as forward)




And when ipa-client-install is run on somehost.lautus.net, it also 
defaults

to LAUTUS.NET for Kerberos domain, as if the default expectation is that
your toplevel company DNS name would be your kerberos domain.

But you can override that.




And when I install a trial IPA server on host ipa-server-1.lautus.net 
using

"ipa-server-install --setup-dns --realm IPA.LAUTUS.NET --domain
ipa.lautus.net --forwarder=8.8.8.8", and then look at the DNS Zones  
in the
Web UI, I see not only ipa.lautus.net, but also lautus, with record 
"@ NS

ipa-server-1.lautus.net". In other words the IPA server defaults to
thinking it owns the domain above ipa.lautus.net too. Which goes against
2.3.1 above.

Interesting. What does "ipa dnszone-find --pkey-only" show?

It seems like it's created an authoritative zone both for the server's 
own domain (lautus.net if the server is xxx.lautus.net) as well as the 
realm's domain (ipa.lautus.net)


I don't know why it's doing that. Now I've checked with another system 
here: the hostname is "ipa-1.int.example.com" and the realm is 
"ipa.example.com", and you're right, it is authoritative for both:


  Zone name: int.example.com.
  Zone name: ipa.example.com.

This isn't what I wanted. The int.example.com domain is hosted 
externally and I didn't want to override it. Right now it's hiding all 
names in int.example.com that it doesn't know about.


I would expect that it's possible to remove this zone, but I'd need to 
test that doesn't stop other hosts called xxx.int.example.com from joining.



Yes and no. What you see with "@ NS ..." is a glue record -- you are
supposed to have a glue record for IPA domain in the upstream domain,
this is how domain delegation works in DNS world.
Aside: technically that's not a glue record. A glue record is an A or 
 record when the NS record points to a host within the subdomain 
which is being delegated. It is to solve the chicken-and-egg situation 
of how to contact a nameserver for a domain before you've contacted a 
nameserver for the domain.


In your case, if you already have working DNS for lautus.net, then you 
don't want FreeIPA to be authoritative for 

Re: [Freeipa-users] 2FA and AllowNTHash

[Brian Candler]

On 03/01/2017 15:28, Maciej Drobniuch wrote:

We have a topo with 3x IPA servers + freeradius.

Freeradius is being used to do mschap with wifi APs. Freeradius 
connects over ldap to IPA.


In order to do the challange-response thing, freeipa has AllowNTHash 
enabled.


So I wanted to enable 2FA/OTP but leave the NTHash as is for wifi auth.

In the moment I disallow Password auth for a user and enable OTP the 
wifi auth stopps working, but the hash clearly stays in ldap.
How are you actually authenticating the user? Are you just reading the 
ipaNTHash out of the LDAP database and letting FreeRADIUS check it? Then 
AFAICS it shouldn't make any different whether OTP is enabled or not.  
Can you show more of your RADIUS config, and the debug output from the 
part which authenticates the user?


I don't use OTP myself, but I wouldn't expect the ipaNTHash to change 
depending on whether OTP is enabled or not (and you're saying the hash 
stays put).


I have what sounds like a similar setup to yours, using FreeRADIUS 
3.0.12 talking to FreeIPA 4.4.0, using a service user which has 
permissions to read out the ipaNTHash directly, based on this blog post:

http://firstyear.id.au/blog/html/2015/07/06/FreeIPA:_Giving_permissions_to_service_accounts..html

ldap config:

base_dn = 'cn=users,cn=accounts,dc=ipa,dc=example,dc=com'

sasl {
mech = 'GSSAPI'
realm = 'IPA.EXAMPLE.COM'
}

update {
control:NT-Password := 'ipaNTHash'
control:Tmp-String-9:= 'krbPasswordExpiration'
}

user {
base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
scope = "one"
}

group {
membership_attribute = 'memberOf'
name_attributes = 'cn'

cacheable_dn = 'yes'
cacheable_name = 'no'
}

default and inner-tunnel authentication is then just:

authenticate {
Auth-Type PAP {
pap
}

Auth-Type MS-CHAP {
mschap
}

eap
}

Also you need to put the service user's keytab somewhere, and set a 
couple of environment variables when it starts, if you want to use 
Kerberos to protect the LDAP connection. Using systemd override:


[Unit]
Requires=dirsrv.target
After=dirsrv.target

[Service]
Environment=KRB5_CLIENT_KTNAME=/etc/radiusd.keytab
Environment=KRB5CCNAME=MEMORY:
Restart=always
RestartSec=5

(Otherwise you can bind with a specific dn and password, but then you 
also need to sort out TLS to secure the LDAP traffic)


There is more magic you can do with the krbPasswordExpiration attribute 
to force the user to do a password change over MSCHAP - but that's now 
straying a long way from what's relevant on a FreeIPA mailing list.


HTH,

Brian.

--
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] 2FA and AllowNTHash

[Brian Candler]

On 05/01/2017 10:57, Maciej Drobniuch wrote:

Maybe I'll paraphrase the question.

It would suffice if I could tell IPA to use pass+otp only instead of 
both (Password+ pass+otp) for particular hosts.

So for example users from hosts X can login with OTP only.

Sorry, I don't understand that.  What are the two passwords you refer 
to, when you say "Password + pass+otp"?


Can you give an example of the type of exchange that goes on now, and 
what you would like it to do instead?


-- 
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] DNS wildcards record for domain

[Brian Candler]

On 31/12/2016 03:08, Outback Dingo wrote:

a bit at a loss here, whats the proper way to add a DNS wildcard for a
domain name to resolve to www.acmewidgets.com if someone type just the
domain acmewigets.com in a browser ?



That's not a wildcard. What you're asking for is two normal records:

www.acmewidgets.com A 192.0.2.1
acmewidgets.com A 192.0.2.1

which you can create using:

ipa dnsrecord-add acmewidgets.com www --a-ip-address=192.0.2.1
ipa dnsrecord-add acmewidgets.com @ --a-ip-address=192.0.2.1


--
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] modify schema - add group email and display attribute

[Brian Candler]

On 02/01/2017 11:53, Sandor Juhasz wrote:
I would be really happy if anybody could assign an OID for the new 
objectcalss


You can get your own enterprise OID for free from here:

http://pen.iana.org/pen/PenApplication.page

Note that you only get one, so it's up to you to subdivide the space. 
For example: if you get 1.3.6.1.4.1.9, then you might decide to use:


1.3.6.1.4.1.9.1 = LDAP object classes

1.3.6.1.4.1.9.1.1 = myMailObjectClass

1.3.6.1.4.1.9.1.2 = someOtherObjectClass

1.3.6.1.4.1.9.2 = LDAP attributes

1.3.6.1.4.1.9.2.1 = mySpecialAttribute

then later you can assign under 1.3.6.1.4.1.9.3 for something else 
that needs OIDs (e.g. SNMP MIBs) and so on.


--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 22/12/2016 20:53, Martin Basti wrote:


(1) This introduces a concept of an "IPA Primary Domain".  Is that 
just the DNS domain which holds the SRV records which point to the 
realm's kerberos/ldap servers, or does it have any other function? In 
other words, what other effects would there be from choosing a 
different IP Primary Domain?


it holds SRV records, A/ records for CA

LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com)



No, I don't believe that's true: the LDAP tree is constructed from the 
*realm* not the *domain*.


I just checked this by creating a Centos7 lxd container with hostname 
"ipa.foo.example.com", running the following command:


# ipa-server-install --domain bar.example.com --realm QUX.EXAMPLE.COM 
--setup-dns -p Abcd1234 -a Defg5678


and accepting defaults for everything else. What I get is:

*** an LDAP tree rooted at dc=qux,dc=example,dc=com

=> this proves the LDAP tree is constructed from the --realm, not the 
--domain.


*** the DNS zone "bar.example.com" (in addition to the reverse zone)

The bar.example.com contains both types of DNS mapping: hostname to 
realm and realm to servers.


(1) _kerberos TXT "QUX.EXAMPLE.COM"

i.e. "hosts with hostnames under domain bar.example.com belong to realm 
QUX.EXAMPLE.COM"


(2) _kerberos._tcp SRV 0 100 88 ipatest.foo.example.com.# plus 
_kerberos._ldap etc


=> this shows the SRV records are put under the --domain


*** in krb5.conf a default realm of QUX.EXAMPLE.COM, and the following 
realm to server mapping:


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

Aha: there is "default_domain" in there! It's a property of the realm! 
Checking the MIT kerberos documentation:


http://web.mit.edu/kerberos/krb5-1.14/doc/admin/conf_files/krb5_conf.html

"default_domain

This tag specifies the domain used to expand hostnames when translating 
Kerberos 4 service principals to Kerberos 5 principals (for example, 
when converting rcmd.hostname to host/hostname.domain)."


So it seems that's only a legacy setting for dealing with kerberos 4 :-(

*** /etc/sssd/sssd.conf

[domain/bar.example.com]
krb5_realm = QUX.EXAMPLE.COM
ipa_domain = bar.example.com

[sssd]
domains = bar.example.com

But in sssd, "A domain is a database containing user information" - from 
sssd.conf(5).  So really it's just a label for a group of settings, 
nothing to do with a DNS domain.


*** CA

grepping through /etc I see some other settings based on the domain, in 
particular the CA hostname is here:


/etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp

However the installation process didn't actually create this DNS entry, 
so the ipa-ca hostname is not resolvable.  Since it has the 
bar.example.com master zone, maybe it should add this record?


*** During the installation I get a reasonable warning:

WARNING: Realm name does not match the domain name.
You will not be able to estabilish trusts with Active Directory unless
the realm name of the IPA server matches its domain name.

But I think this also highlights confusion between "the IPA domain" and 
"the server's domain name".


It's clear is that the *realm* is something that's common to all the IPA 
servers.  However it's also clear that each IPA server's *hostname* can 
be in a different *domain*, e.g. they could be


srv1.bar.com
srv2.baz.com

But "the IPA primary domain" (where the SRV records are stored) is an 
attribute of the realm collectively, not of the individual servers.  So 
it might be clearer if it said:


WARNING: Realm name does not match the domain name.
You will not be able to establish trusts with Active Directory unless
the IPA realm matches the IPA primary domain.




Then use bar.example.com, IPA servers can have names outside the IPA 
domain name space.


Different people wants different things, that's why the option is there.



Indeed, but the "--domain" option to ipa-server-install appears to be 
orthogonal to the domain name of the IPA servers themselves. This is a 
primary source of confusion I think.


Regards,

Brian.

--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 23/12/2016 09:47, Brian Candler wrote:
/etc/pki/pki-tomcat/ca/CS.cfg:ca.defaultOcspUri=http://ipa-ca.bar.example.com/ca/ocsp 



However the installation process didn't actually create this DNS 
entry, so the ipa-ca hostname is not resolvable.


Aside: I think this was because ipatest.foo.example.com was only in 
/etc/hosts, not in the DNS. Installation message:


ipa : ERRORunable to resolve host name 
ipatest.foo.example.com. to IP address, ipa-ca DNS record will be incomplete


But if it had used gethostent() or similar, it would have worked:

# getent hosts ipatest.foo.example.com
100.64.2.3  ipatest.foo.example.com ipatest

Regards,

Brian.

--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 23/12/2016 10:31, Alexander Bokovoy wrote:

ipa-ca used to be a CNAME, you cannot handle CNAME via /etc/hosts.
However, multiple replicas cannot me specified via CNAME, so we had to
fix https://fedorahosted.org/freeipa/ticket/3547. 


Absolutely - I have no problem with ipa-ca being real A record(s) 
pointing to the server itself.


All I'm saying is that at installation time, it already knew the IP 
address of the server - by local hostname resolution, and because 
ipa-server-install  asks you to list the IP addresses of the server 
explicitly.


> The ipa-ca A record is now handled as part of the server upgrade which
> also should be run at the very end of a normal install.

Are you are supposed to manually run "ipa-server-upgrade" even after a 
clean install?


I've just tested that, and yes, one of the steps is:

...
[Add missing CA DNS records]
Updating DNS system records
<< pauses here >>
unable to resolve host name ipatest.foo.example.com. to IP address, 
ipa-ca DNS record will be incomplete

...

So you're right: that would have fixed it *if* I'd created the 
foo.example.com zone first, and added the host to it, which in real life 
I would have done (since other hosts must be able to resolve the IPA 
server's hostname)


I already opened https://fedorahosted.org/freeipa/ticket/6579 which 
suggested using local resolution, e.g. via gethostent(). But feel free 
to close it if you don't think this is needed.


Regards,

Brian.

--
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Brian Candler]

On 20/12/2016 08:07, Petr Spacek wrote:

I've tried to clarify things in man pages and on web as well. Please have a
look to changes and let us know if it is better or not, and preferably what
can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are here:
https://github.com/freeipa/freeipa/pull/352


Thank you for working on this.

This is getting clearer, but I would like to expand a little more.

(1) This introduces a concept of an "IPA Primary Domain".  Is that just 
the DNS domain which holds the SRV records which point to the realm's 
kerberos/ldap servers, or does it have any other function? In other 
words, what other effects would there be from choosing a different IP 
Primary Domain?


Let me give a specific example.

- IPA server hostname is ipa.foo.example.com
- I want to create kerberos realm BAR.EXAMPLE.COM

Which IPA primary domain should I choose?

The expected place for SRV records for realm BAR.EXAMPLE.COM would be in 
the DNS under domain bar.example.com.  So I'm thinking that "--domain 
bar.example.com" is the right thing - and can't think why you'd ever 
want to do anything else.




(2) I'm trying to work out how --domain, --realm, --server and 
systemhostname influence each other, if one or more is not provided.


For ipa-server-install, testing suggests:

* --domain defaults to the domain part of the system hostname
* --realm defaults to the uppercased --domain
* (--server is obviously itself :-)

For ipa-client-install it seems a bit more complex. Based on the 
manpage, I believe the sequence is something like this:


* If --domain is not specified, then it's the domain from the system 
hostname
* If --server is not specified, then it hunts for servers based on the 
--domain (looking in that domain and its parents until suitable SRV 
records are found)
* If --realm is not specified, then it sends a query to the --server(s) 
to ask what realm they are in


But the manpage says you can specify both --server and --domain:

  "Client  machine  can  also be configured without a DNS 
autodiscovery at all. When both
   --server and --domain options are used, client installer will 
use the specified server

   and  domain  directly."

In that case, I can't see what the --domain is used for here, if it's 
only purpose is to locate servers (and you've already told it which 
--server to use)


Thanks,

Brian.

--
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] NTLM SASL?

[Brian Candler]

Question: does FreeIPA (or specifically the 389 directory server) 
implement the NTLM SASL mechanism?


It appears not at first attempt:

# yum install cyrus-sasl-ntlm
# ldapsearch -Y NTLM
SASL/NTLM authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: sasl mechanism not supported

Now, under cn=config, I see:

nsslapd-allowed-sasl-mechanisms:

(i.e. empty).

I tried changing this to "NTLM" and it accepted the change. If I try 
changing it to "ntlm" I get "Server is unwilling to perform" - which is 
a good sign, since clearly "NTLM" is valid.


However even after restarting the server, I still get "sasl mechanism 
not supported" when I try the bind.


-=-=-=-

The reason I'm asking: I'm using FreeRADIUS for MSCHAP authentication, 
and one of the things MSCHAP supports is a password change feature for 
expired passwords. FreeRADIUS lets me shell out to an external process 
to perform the password change:


local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd 
'%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' 
'%{control:NT-Password}'"


Now, the last argument is the user's *old* NTLM password hash. So 
ideally I would use this to authenticate to the FreeIPA server to 
perform the password change - this would avoid the freeipa-passwd script 
having to have any privileged credentials of its own.


But the only way I can think of doing that would be via a SASL NTLM bind.

Regards,

Brian.

--
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] Kerberos realm for different domain

[Brian Candler]

On 16/12/2016 10:19, Alexander Bokovoy wrote:
I want to allow users in the AD.EXAMPLE.COM realm to login to 
machines in the IPA.EXAMPLE.COM realm.


Will this still work when the machines are in different DNS domains? 

Yes, it will. Here is the catch: you need to make sure these different
DNS domains all mentioned in 'ipa realmdomains-show' and if not, they
should be added by use of 'ipa realmdomains-mod'. None of these domains
must overlap with Active Directory domains, of course. 


Fantastic answer. Thank you so much for taking the time to explain this.

Regards,

Brian.

-- 
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] NTLM SASL?

[Brian Candler]

On 22/12/2016 12:48, Simo Sorce wrote:

Sorry Brian but we do not support SASL NTLM or SASL SPNEGO/NTLM at this
time, to do that you not only need the mechanism but also a way for that
mechanism to either contact a NT-like Domain Controller or have direct
access to the NT password hashes for any user you want to authenticate,
and none of that is set up by default.
I installed ipa-server-trust-ad, and FreeIPA is storing the ipaNTHash 
attribute. The RADIUS server uses a privileged principal which has 
permissions to read out this attribute, and then it uses that to 
authenticate users.


All works nicely - even password changing for expired passwords over 
MSCHAPv2. However the password-change script currently needs a 
privileged FreeIPA principal (permitted to change anyone's password), 
which also needs to be in passSyncManagersDNs so that the changed 
passwords aren't immediately expired. And unfortunately that means it 
also bypasses FreeIPA's password complexity tests, so I have to 
implement those externally.


Some FreeRADIUS config snippets below, in case anyone's interested.


We are planning to enable the integrated Samba server (which is used for
trusts only at the moment) to provide NTLM services for radius servers,
but it is not ready yet, although you may try to experiment with it.


I could give it a try, although if it's not in 4.4.0 I'd have to set up 
a separate testbed for it.  If the new code includes NTLM password 
changing that would certainly simplify things a lot.


Cheers,

Brian.


# mods-available/ldap

update {
control:NT-Password:= 'ipaNTHash'
control:Tmp-String-9:= 'krbPasswordExpiration'
}

user {
base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
scope = "one"
# 
https://www.redhat.com/archives/freeipa-users/2011-June/msg00078.html

access_attribute = "nsaccountlock"
access_positive = no
}

group {
membership_attribute = 'memberOf'
name_attributes = 'cn'
cacheable_dn = 'yes'
cacheable_name = 'no'
}

# mods-available/eap

eap {
  mschapv2 {
send_error = yes
  }
}

# mods-available/mschap

local_cpw = "%{exec:/usr/local/sbin/freeipa-passwd 
'%{mschap:User-Name}' '%{MS-CHAP-New-Cleartext-Password}' 
'%{control:NT-Password}'}"


# policy.d

password_expiry {
  # 
https://github.com/FreeRADIUS/freeradius-server/blob/v3.0.x/doc/modules/mschap.rst

  # http://wiki.freeradius.org/config/run_time_variables
  if (:Tmp-String-9 < "%D%H%G00Z") {
update control {
   := '[Ue]'
}
  } else {
update control {
   := '[U]'
}
  }
}


--
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] NTLM SASL?

[Brian Candler]

On 22/12/2016 14:08, Alexander Bokovoy wrote:

dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
-
# accepted, but doesn't change the value of the attribute

So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI 
EXTERNAL". But that means this server is in a different config state 
to its replica peers, which I wonder might bite me one day.

You can shut the server down (ipactl stop), change the value in the
config (/etc/dirsrv/slapd-INSTANCE/dse.ldif) and start the server again
(ipactl start). 


Thank you.  I looked in this file and the setting wasn't there! But a 
bit more investigation showed that the following update *does* update 
the config in dse.ldif:



dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
-


However the doesn't become visible until you restart the server. Until 
then, doing an ldapsearch on cn=config returns the previous value of 
this attribute.


Anyway, all is good now.

Thanks again,

Brian.
-- 
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] NTLM SASL?

[Brian Candler]

On 22/12/2016 11:42, Brian Candler wrote:

Now, under cn=config, I see:

nsslapd-allowed-sasl-mechanisms:

(i.e. empty).

I tried changing this to "NTLM" and it accepted the change. 


Aside: I'm also stuck changing it back to what it was :-(

None of these works:

dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:
-
# Server is unwilling to perform (53)

dn: cn=config
changetype: modify
delete: nsslapd-allowed-sasl-mechanisms
-
# Server is unwilling to perform (53)
#additional info: Deleting attributes is not allowed

dn: cn=config
changetype: modify
replace: nsslapd-allowed-sasl-mechanisms
-
# accepted, but doesn't change the value of the attribute

So for now, I've set "nsslapd-allowed-sasl-mechanisms: GSSAPI EXTERNAL". 
But that means this server is in a different config state to its replica 
peers, which I wonder might bite me one day.


Thanks,

Brian.

--
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] Disabling OTP for sudo

[Brian Candler]

Question: can I remove the need for OTP for sudo access, when used with 
an account that has OTP enabled?


All I could find was this mail from mid-2015:

https://www.redhat.com/archives/freeipa-users/2015-July/msg00336.html

It said that sssd would need some changes.

I don't know how sssd itself validates the password provided (is it via 
Kerberos? Does it also depend on authentication indicators being 
implemented?)


Thanks,

Brian.

--
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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

It turns out we had another 16.04 machine which was working fine. But as 
soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 1.8.16-0ubuntu1.3, 
it stopped working too.


So it looks like I have a reproducing case for this and I can 
investigate further - I suspect it's a behaviour change from this fix:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666

--
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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

Hi,

I have FreeIPA set up under CentOS 7.  When I use freeipa-client to add 
an ubuntu 14.04 client it works fine (*). However when do the same with 
ubuntu 16.04, sudo always refuses to run:


$ sudo -s
[sudo] password for brian.candler:
brian.candler is not allowed to run sudo on api-dev.int.example.com.  
This incident will be reported.


I have a simple one-entry sudo policy which says that for all users in 
groups X and Y, on all hosts, run all commands.  (**)


If I crank up sudo logging by setting this in /etc/sudo.conf:

Debug sudo /var/log/sudo-debug all@info

then on the working 14.04 machine I see

... various settings ...
May  2 22:05:27 sudo[19175] settings: plugin_dir=/usr/lib/sudo/
May  2 22:05:27 sudo[19175] user_info: user=brian.candler
May  2 22:05:27 sudo[19175] user_info: pid=19175
... lots more user_info, perms, netgroups etc ...
May  2 22:05:29 sudo[19175] policy plugin returns 1
...

but on the failing 16.04 machine I see only this:

May  3 07:44:56 sudo[21118] will restore signal 13 on exec
May  3 07:44:56 sudo[21118] comparing dev 34817 to /dev/pts/1: match! @ 
sudo_ttyname_dev() ./ttyname.c:336

May  3 07:44:56 sudo[21118] settings: run_shell=true
May  3 07:44:56 sudo[21118] settings: progname=sudo
May  3 07:44:56 sudo[21118] settings: 
network_addrs=x.x.x.x/255.255.255.0 
:::::230/::::::: 
fe80::1:::/:::::

May  3 07:44:56 sudo[21118] settings: plugin_dir=/usr/lib/sudo/
May  3 07:44:58 sudo[21118] policy plugin returns 0

That's all that gets logged - nothing more.  It seems that a return of 0 
means failure:


https://www.sudo.ws/man/1.8.15/sudo_plugin.man.html

"open()
...
Returns 1 on success, 0 on failure, -1 if a general error occurred, or 
-2 if there was a usage error."


But I have no idea what sort of failure or why.

/var/log/auth.log shows:

May  3 08:00:14 api-dev sudo: pam_unix(sudo:auth): authentication 
failure; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 
ruser=brian.candler rhost=  user=brian.candler
May  3 08:00:14 api-dev sudo: pam_sss(sudo:auth): authentication 
success; logname=brian.candler uid=121103 euid=0 tty=/dev/pts/1 
ruser=brian.candler rhost= user=brian.candler
May  3 08:00:14 api-dev sudo: brian.candler : user NOT in sudoers ; 
TTY=pts/1 ; PWD=/home/brian.candler ; USER=root ; COMMAND=/bin/bash


(which shows I gave the correct FreeIPA password, but not why the 
sudoers lookup failed)


I really can't see where else to look. Both machines have "sudo: files 
sss" in /etc/nsswitch.conf, and both have the same /etc/sssd/sssd.conf.  
Setting "sss_debuglevel 7" and "sss_cache -UG" shows a lot of noise but 
no obvious errors.


I've also upgraded to the latest sudo_1.8.19-3_amd64.deb package from 
https://www.sudo.ws/download.html, but this makes no difference.


Has anyone seen this problem before, or have some ideas where else to look?

Thanks,

Brian Candler.


(*) In Ubuntu 14.04 I had to manually add sudo to the list of sssd services:

|[sssd]|
|services = nss, pam, ssh, sudo|

but this was done automatically by freeipa-client in Ubuntu 16.04.

(**) Therefore I'm pretty sure this is not the netgroups problem, for 
which the fix has been released anyway:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1607666
-- 
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] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

> do you have 'sudo: files sss" or "sudoers: files sss"? The former 
doesn't do anything, the latter is correct.


My mistake, I meant

sudoers: files sss

But oddly, out of the three 16.04 boxes I set up and enrolled, it was 
missing on one of them - and this happened to be the one I was checking 
logs on :-(  (However, sudo fails in the same way on all three machines)


So after adding this I've rechecked logs.

/var/log/sudo-debug is the same, in particular it still shows "policy 
plugin returns 0" and nothing after.


With sss_debuglevel 5, /var/log/sssd/sssd_IPA.EXAMPLE.COM.log has

...
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): ruser: brian.candler
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): rhost:
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): authtok type: 0
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): newauthtok type: 0
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): priv: 0
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): cli_pid: 22709
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] [pam_print_data] 
(0x0100): logon name: not set
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[ipa_hostgroup_info_done] (0x0200): Dereferenced host group: normal_hosts
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[ipa_hostgroup_info_done] (0x0200): Dereferenced host group: 
development_hosts
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[hbac_get_category] (0x0200): Category is set to 'all'.
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule 
[allow_normal_hosts]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) 
[Success]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) 
[Success]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Sending result [0][IPA.EXAMPLE.COM]
(Wed May  3 08:50:37 2017) [sssd[be[IPA.EXAMPLE.COM]]] 
[be_pam_handler_callback] (0x0100): Sent result [0][IPA.EXAMPLE.COM]


("allow_normal_hosts" is indeed the name of the rule in FreeIPA database)

sssd.log has:

(Wed May  3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
Received client version [1].
(Wed May  3 08:50:35 2017) [sssd[nss]] [sss_cmd_get_version] (0x0200): 
Offered version [1].
(Wed May  3 08:50:35 2017) [sssd[nss]] [sss_parse_name_for_domains] 
(0x0200): name 'root' matched without domain, user is root
(Wed May  3 08:50:35 2017) [sssd[nss]] [nss_cmd_getbynam] (0x0100): 
Requesting info for [root] from []
(Wed May  3 08:50:35 2017) [sssd[nss]] [nss_cmd_initgroups_search] 
(0x0080): No matching domain found for [root], fail!
(Wed May  3 08:50:37 2017) [sssd[nss]] [client_recv] (0x0200): Client 
disconnected!


(Hmm, suspicious that error about "root" ??)

sssd_sudo.log has:

(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200): 
Received client version [1].
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_cmd_get_version] (0x0200): 
Offered version [1].
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] 
(0x0200): Requesting default options for [brian.candler] from []
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): 
Requesting info about [brian.cand...@ipa.example.com]
(Wed May  3 08:50:35 2017) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=brian.candler)(sudoUser=#121103)(sudoUser=%security_administrators)(sudoUser=%admins)(sudoUser=%network_readonly)(sudoUser=%vpn)(sudoUser=%system_administrators)(sudoUser=%ipausers)(sudoUser=%staff)(sudoUser=%brian.candler)(sudoUser=+*))(&(dataExpireTimestamp<=1493801435)))]
(Wed May  3 08:50:35 2017) [sssd[sudo]] 
[sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with 
[(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sss_parse_name_for_domains] 
(0x0200): name 'brian.candler' matched without domain, user is brian.candler
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_cmd_parse_query_done] 
(0x0200): Requesting rules for [brian.candler] from []
(Wed May  3 08:50:35 2017) [sssd[sudo]] [sudosrv_get_user] (0x0200): 
Requesting info about 

Re: [Freeipa-users] ubuntu 16.04 freeipa-client + sssd + sudo: "policy plugin returns 0"

[Brian Candler]

On 03/05/2017 15:05, Brian Candler wrote:
It turns out we had another 16.04 machine which was working fine. But 
as soon as I updated its sudo from 1.8.16-0ubuntu1.2 to 
1.8.16-0ubuntu1.3, it stopped working too.


So it looks like I have a reproducing case for this and I can 
investigate further 


FYI, I finally got to the bottom of this issue.

(1) The groups referred to in the sudo rule had been created as 
non-posix groups in FreeIPA


(2) It seems that the old sudo in Ubuntu wasn't checking groups at all, 
and the new one did.  But it could not see non-posix groups.


(3) I solved the problem by adding "objectClass: posixgroup" and 
"gidNumber: NN" to the groups.


More details at:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1688034/comments/4

Aside: I discovered that the way to debug the sudoers plugin is like this:

Debug sudo /var/log/sudo-debug all@info
Debug sudoers.so /var/log/sudoers-debug all@info

(I had originally missed off the ".so" suffix)

It's a bit frightening that sudo+sssd was not enforcing policies 
correctly, for who knows how long.


Regards,

Brian.

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