Re: [Freeipa-users] NTLM SASL?
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?
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 (&control:Tmp-String-9 < "%D%H%G00Z") {
update control {
&SMB-Account-Ctrl-Text := '[Ue]'
}
} else {
update control {
&SMB-Account-Ctrl-Text := '[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?
On to, 22 joulu 2016, Brian Candler wrote: 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. 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). -- / 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] NTLM SASL?
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
Re: [Freeipa-users] NTLM SASL?
On Thu, 2016-12-22 at 11:42 +, Brian Candler wrote:
> 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.
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.
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.
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] NTLM SASL?
On to, 22 joulu 2016, Brian Candler wrote:
Question: does FreeIPA (or specifically the 389 directory server)
implement the NTLM SASL mechanism?
No, it doesn't. Even if you install cyrus-sasl-ntlm module, 389-ds will
not be able to authenticate:
[22/Dec/2016:14:16:08.920773153 +0200] conn=20 fd=109 slot=109 SSL connection
from 192.168.5.196 to 192.168.5.196
[22/Dec/2016:14:16:08.926439405 +0200] conn=20 TLS1.2 128-bit AES
[22/Dec/2016:14:16:08.929793115 +0200] conn=20 op=0 BIND
dn="uid=foobar,cn=users,cn=accounts,dc=split,dc=test" method=sasl version=3
mech=NTLM
[22/Dec/2016:14:16:08.930458789 +0200] conn=20 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[22/Dec/2016:14:16:11.841985315 +0200] conn=20 op=1 BIND
dn="uid=foobar,cn=users,cn=accounts,dc=split,dc=test" method=sasl version=3
mech=NTLM
[22/Dec/2016:14:16:11.843719821 +0200] conn=20 op=1 RESULT err=49 tag=97 nentries=0 etime=0 - SASL(-14): authorization failure:
[22/Dec/2016:14:16:11.843761905 +0200] conn=20 op=2 UNBIND
[22/Dec/2016:14:16:11.843771888 +0200] conn=20 op=2 fd=109 closed - U1
The reason for that is due to how SASL support is implemented in 389-ds:
it only supports those SASL mechanisms which don't require direct
access to the userPassword attribute (GSSAPI). Alternatively, if
userPassword contains a clear-text password, those SASL mechanisms that
require access to the clear text password will also work.
FreeIPA does not store clear text password, so no chance for SASL
DIGEST-MD5 or SASL NTLM.
-=-=-=-
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.
Sorry, this is not going to work.
--
/ 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] NTLM SASL?
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
