Re: [Freeipa-users] change min and max lifetime of random password
On Mon, 24 Mar 2014, Stijn De Weirdt wrote:
hi alexander,
No, because then you have to either ship keytabs around during
provisioning or hardcode that user's password in the kickstart and
they are already nervous about doing that for the OTP.
This topic raises regularly on IRC. My suggestion was to create these
one time passwords based on some function of time and host parameters
you can control centrally, for example, IP address.
For example, using Python expression:
from time import gmtime
addr = 192.168.0.1
time = lambda t : list(t[:4]) + [(t[4] / 15) * 15]
pw = lambda t, a: ''.join(a.split('.') + map(lambda x:
'{:02d}'.format(x), t))
pw(time(gmtime()), addr)
'19216801201403242030'
i.e. a password is an IP address octets concatenated with date and time
rounded down to 15 minutes.
Then ship the function to calculate the OTP as part of kickstart file.
Only a password generated when running install within 15 minutes window of
setting OTP on the server will work if IP address is the same as defined
on the server.
No real password is in the kickstart file, OTP will turn itself off
automatically on enrollment and time has to be within the window of
opportunity.
but the password itself is still valid if the install failed and
someone else tries to use it.
Right. Nobody actually prevents you from running a cron job on the
server side to lock down these passwords if they were not used up in
a fixed amount of time.
it's good that you can't guess the password that easily (it's
slightly better than a fixed string in the kickstart script), might
be a good candidate if it was coupled with a short enough lifetime.
(coupled with minimum lifetime as an offset, you might even schedule
installations in the future).
i don't understand what the ip adds to the password though. the
ipa-client-install should fail if the ip/hostname doesn't match the
data in freeipa for that host, right? (the only secret is in the
timewindow that the admin scheduled, assume that the
ipa-client-install enforces the ip/hostname)
In a typical environment you have central control over those types of
data associated with the spawned machines, like MAC addresses or IP
addresses.
If the password is including bits that are forced to the host by a
central authority, it makes harder to get rogue clients to re-use the
same template for other combinations of MAC/IP address. They would need
to know exact IP or MAC address of the machine they want to impersonate.
You can take other unique parameters into account.
You need to think of what is truly unique to your clients but there
still will be question of trust to the client who attempts to
authenticate. This trust should be verified on multiple levels, a
password to enroll the client is just one of them.
--
/ Alexander Bokovoy
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] External Collaboration Domains
On Tue, 25 Mar 2014, Nordgren, Bryce L -FS wrote: Collaboration can be in different ways. It all depends on the use case. It can be OpenID, SAML, Kerberos, etc. There are different technologies and they suit better different use cases. Can you please share under what circumstances such inversion would actually be needed? Console logins in a domain specifically created for collaboration with external entities. Expect that there is a one-way trust from the organization's internal domain (providing users) to the collaboration domain (providing services). The collaboration domain would host services and devices necessary for the execution of various projects. Project members are NOT from a small set of closely knit organizations, where it is feasible to establish cross domain trusts. As this is a large organization, many projects are starting, in-progress, and ending at all times. New projects do not necessarily require trusts to the same set of organizations as existing or finishing projects. Services may be web services, shared filesystems, standalone processing machines, and high performance computing assets. The services have service or host principals in the collaboration domain's domain controller. From an IT perspective, this is similar to interacting with customers, except the customer! s deploy and/or access stuff on your network. Much of the horsepower in this domain will probably be some variant of Linux. There are instances of high-horsepower Windows and Mac devices/clusters, but they are not common. Source code control, issue trackers, networked filesystems, datafiles, and metadata development webapps have a presence here. Esoteric scientific equipment may be connected to the network, but will probably not be Kerberized (i.e., Gas Chromatograph Mass Spectrometer). Terminals may be Mac, Windows, Linux, Android or iOS and may belong to guests. This is just in my building in Montana. Nationwide the situation is likely to be more chaotic. The big reason everything is here: it either violates enterprise policy or needs to be accessible by external users (which violates enterprise policy). to sum up above, you'd need POSIX identities for users and groups coming from nowhere to be created and associated with their external credentials. This is not really different from what many web sites do which accept 3rd-party authentication promise but then create own accounts once you've passed through OAuth2, for example. So you would have an IPA domain where you would have a portal that creates users after they successfully authenticated to a third-party you trust. FreeIPA 4.0 will have support for external RADIUS server authentication as a token that can be associated with a user. Note that this user has to be created first but overall this is doable. However, consequent logins through console would assume you are actually using your third-party password or two-factor auth directly. This means no previously issued OAuth2 assurance can be of any help here as you are not dealing with a browser here that obtained the assurance. May be at this point it would make sense to actually switch the user to some generated password or 2FA unique to the collaboration domain? If such a domain were to exclusively contain web services, one wouldn't need a domain controller at all. Something like gluu or openam would suffice. But I need to share files and support console access in addition to web access. Using the same credentials. Which I don't want to manage. For web services exclusively, a scheme with external RADIUS provided token is OK. If the KDC is bundled as part of a larger directory solution like IPA/AD, then some extra overhead (SID/UID) needs to be synthesized for use within the domain when the identity is first encountered. This is not more work than offering your realm's services to Kerberos users (from IPA? AD? Kerberos+LDAP? Just Kerberos?) who arrive from a foreign realm (via PKINIT or trust) when you have no way to access this non-kerberos information in the user's home realm. Letting the local domain controller do it guarantees it's harmonized within the realm. See above. There has to be a standardized method for encoding these foreign user principal names and realms. You want subsequent logins to use the same principal (and same SID/UID). You also want the principal name and realm to be the same no matter how it shows up in your realm (e.g., via direct login or via a trust). This may involve the creation of zero or more new Kerberos nametypes. I don't think you really need to invent something here. Authenticate over some third-party source at sign-up, ask user to accept terms of use, create IPA user for the user, associate external token with the IPA user based on already obtained OAuth2 token user gave you when signed up. Keep external identity in the IPA user account: ipa user-add user --radius=radiusproxy-name \ --radius-username=external-name \
Re: [Freeipa-users] change min and max lifetime of random password
hi alexander, No real password is in the kickstart file, OTP will turn itself off automatically on enrollment and time has to be within the window of opportunity. but the password itself is still valid if the install failed and someone else tries to use it. Right. Nobody actually prevents you from running a cron job on the server side to lock down these passwords if they were not used up in a fixed amount of time. hence my request for password expiration. ity would be good anyway to have a script that checks all hosts that have not enrolled yet how old the issued password is (even after expiration). very useful to spot the state of ongoing deployments and to spot problems. how can one obtain the creation time of the password? fetch the timestamp from LDAP or is there a nice ipa API for it? it's good that you can't guess the password that easily (it's slightly better than a fixed string in the kickstart script), might be a good candidate if it was coupled with a short enough lifetime. (coupled with minimum lifetime as an offset, you might even schedule installations in the future). i don't understand what the ip adds to the password though. the ipa-client-install should fail if the ip/hostname doesn't match the data in freeipa for that host, right? (the only secret is in the timewindow that the admin scheduled, assume that the ipa-client-install enforces the ip/hostname) In a typical environment you have central control over those types of data associated with the spawned machines, like MAC addresses or IP addresses. If the password is including bits that are forced to the host by a central authority, it makes harder to get rogue clients to re-use the same template for other combinations of MAC/IP address. They would need to know exact IP or MAC address of the machine they want to impersonate. You can take other unique parameters into account. You need to think of what is truly unique to your clients but there still will be question of trust to the client who attempts to authenticate. This trust should be verified on multiple levels, a password to enroll the client is just one of them. as dmitry pointed out in previous mail, i was mistaken that IPA has tight coupling by default between hostname and IP (the DNS is optional). anyway, thanks again for the feedback. stijn ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install fails on replica because of kinit cannot contact any KDC
It searching for ldap.mydomain.com because you still have DNS SRV record
_kerberos._udp.mydomain.com. pointing to it. I would start there.
As for the failure, I would check that the generated /etc/krb5.conf is correct:
~
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = MYDOMAIN.COM
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MYDOMAIN.COM = {
kdc = ldap2.mydomain.com:88
master_kdc = ldap2.mydomain.com:88
admin_server = ldap2.mydomain.com:749
default_domain = mydomain.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
.mydomain.com = MYDOMAIN.COM
mydomain.com = MYDOMAIN.COM
(I assume you did more anonymizing that expected, ipa-client-install does not
generate 2 domain_realm mappings unless client domain is different that server
domain (e.g. client.other.mydomain.com and server.mydomain.com)).
What I would do in your place is to:
1) Backup your current /etc/krb5.conf
2) Replace it with the krb5.conf which was generated during ipa-client-install
(you can find non-anonymized version in ipaclient-install.log)
3) Try to kinit: kinit skarul...@mydomain.com
Then it will be easier to troubleshoot. To get more information what kinit
actually does, try enabling a trace:
# KRB5_TRACE=/dev/stdout kinit skarul...@mydomain.com
You will be then able to see if it really connects to right IP address which
would enable you to debug further.
Martin
On 03/24/2014 07:20 PM, Shree wrote:
If you look at the attached logs, you can see it is going to the correct dns
server. dig information is also correct. There is something else going on I
can figure out what?
Shreeraj
Change is the only Constant !
On Saturday, March 22, 2014 2:12 PM, Dmitri Pal d...@redhat.com wrote:
On 03/21/2014 07:44 PM, Shree wrote:
Hi
Attaching the install log. It complains about unable to reach
certain ports, however my tests by using telnet were successful.
Also to refresh your memory the client should be reaching for
the replica lda2.mydomain.com and not ldap.mydomain.com which it
does for the most part but I found a couple of instances of
ldap.mydomain.com in the log. Let me know what you find. I can't
believe I migrated over 40 servers and only this one refuses to
install ipa-client.
If it is getting to the wrong server then it is either looking at
the wrong DNS server (see resolve.conf) which is telling it to use
the wrong IPA server (may be from some old try/POC) or it has some
explicit entries entered in /etc/hosts.
Shreeraj
Change is the only Constant !
On Thursday, March 20, 2014 4:29 AM, Martin Kosek mko...@redhat.com wrote:
On 03/19/2014 10:37 PM, Shree wrote:
Hello
I was able to successfully move all my clients to
the replica except on the process I had to upgrade the
client to ipa-client-3.0.0-37.el6.x86_64 and some
times run a --uninstall
. Bit it works for the most part. Have been
struggling with one last host with errors like below.
I have tested the port connectivity using telnet and
netcat commands but the install thinks these ports are
blocked?
kerberos authentication failed
kinit: Cannot contact any KDC for realm
'MYDOMAIN.COM' while getting initial credentials
Please make sure the following ports are opened
in the firewall settings:
TCP: 80, 88, 389
UDP: 88 (at least one of TCP/UDP ports 88
has to be open)
Also note that following ports are necessary for
ipa-client working properly after enrollment:
TCP: 464
UDP: 464, 123 (if NTP enabled)
Installation failed. Rolling back changes.
Disabling client Kerberos and LDAP configurations
Redundant SSSD configuration file
/etc/sssd/sssd.conf was moved to
/etc/sssd/sssd.conf.deleted
Restoring client configuration files
Client uninstall complete.
[root@www /]#
In the /var/log/ipaclient-install.log I also see
things like below. I get Autodiscovery failures but I
am manually entering things and they have been
working.
2014-03-19T21:13:47Z DEBUG Found:
cn=MYDOMAIN.COM,cn=kerberos,dc=mydomain,dc=com
2014-03-19T21:13:47Z DEBUG Discovery result:
Success; server=ldap2.mydomain.com,
domain=mydomain.com, kdc=ldap.mydomain.com,
[Freeipa-users] using 3rd party cert not self sign cert in ipa
Dear all: whe install it already genrate a self sign cert called mydomain.com . and run ca service. now i want to check if it ok to install 3rd party replcacing ..so to httpd my ldap it will be https: my co domain (official cert ). and replcabelow. /etc/ipa/ca.crt /usr/share/ipa/html/ca.crt Is it possible ? or any side effect on the infrsturture if chane the cert,. http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP I saw some info on web ...but i now already launch and many users connected. if i replaced the cert will it make the ldap invalid for exisiting users.??? Regafs Barry ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] using 3rd party cert not self sign cert in ipa
On 25.3.2014 10:27, barry...@gmail.com wrote: Dear all: whe install it already genrate a self sign cert called mydomain.com http://mydomain.com . and run ca service. now i want to check if it ok to install 3rd party replcacing ..so to httpd my ldap it will be https: my co domain (official cert ). and replcabelow. /etc/ipa/ca.crt /usr/share/ipa/html/ca.crt You don't have to touch these files if you only want to install your own certificates for HTTP and LDAP. Is it possible ? or any side effect on the infrsturture if chane the cert,. http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP I saw some info on web ...but i now already launch and many users connected. if i replaced the cert will it make the ldap invalid for exisiting users.??? You must make sure the CA certificate that signed your HTTP and LDAP certificates is trusted on your client systems. If you do that, everything should work fine. Regafs Barry Honza -- Jan Cholasta ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] HBAC for mod_auth_kerb (and give karma to Fedora 20 package)
Hello, so you've read about the web application authentication and host-based access control but never tried it and now you wonder how the HBAC with Kerberos actually works in the web context ... Why not try to set it up and see for yourself? ... And give karma to https://admin.fedoraproject.org/updates/mod_authnz_pam-0.9-1.fc20 to get http://fedorapeople.org/cgit/adelton/public_git/mod_authnz_pam.git/commit/?id=3ddf467cbadba121e878699da74b26351a31e547 in if you find it satisfactory. You can use http://www.freeipa.org/page/Web_App_Authentication as the guidelines but you can also try to set things up completely without the guides, just using mod_authnz_pam's documentation at http://www.adelton.com/apache/mod_authnz_pam/ And comments and help with the karma would be appreciated. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] AD trusts HBACs such
I've been working with support on how to set up HBAC and sudo rules with AD users. From what they've described I can only manage them on an aggregate level using an external group. For example, I can define an hbac rule, but that hbac rule will be vaild for *all* AD users in the external group that was created to handle them. Am I missing something? If that's the case then this isn't flexible enough for our needs. I have to be able to specify rules based on individual accounts. It seems like there might be a work-around by using multiple external groups and having each AD user in their own external group, but that would be really cumbersome (if it's even possible.) Do I have any other options? Thanks, --Jason ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] AD trusts HBACs such
On Tue, 25 Mar 2014, KodaK wrote: I've been working with support on how to set up HBAC and sudo rules with AD users. From what they've described I can only manage them on an aggregate level using an external group. For example, I can define an hbac rule, but that hbac rule will be vaild for *all* AD users in the external group that was created to handle them. Am I missing something? If that's the case then this isn't flexible enough for our needs. I have to be able to specify rules based on individual accounts. It seems like there might be a work-around by using multiple external groups and having each AD user in their own external group, but that would be really cumbersome (if it's even possible.) Do I have any other options? Group membership in IPA follows LDAP membership rules. This means objects must have DN to be included into an LDAP group. AD users do not exist in IPA LDAP server, thus they cannot be referenced by DN. HBAC rules refer objects by their LDAP DNs too. To overcome absence of LDAP DNs for AD users and groups we have concept of external groups in IPA LDAP. These are normal LDAP groups, that lack POSIX attributes and have special attribute to store SIDs of external objects which 'belong' to this group. We then use DN of the external group to be a member. When SSSD evaluates HBAC groups against certain AD user, it uses group membership from Keberos ticket defined in MS-PAC structure to verify against the set of HBAC rules. That group membership in the MS-PAC is defined in terms of SIDs. SSSD downloads all HBAC rules related to the host, then unrolls all groups that are referenced in the HBAC rules and applies special handling to external groups by taking that specific attribute which stores SIDs of external group members. So at this point SSSD has all information to match SIDs of AD user against HBAC rules. There is no other way to do it. So there are two ways to handle your case -- by grouping at IPA side or by grouping at AD side. The latter approach is to have a group in AD that says these users have access to this server and make an external group in IPA that references the AD group. By deleting AD user from AD group you will effectively deny access to an IPA machine without touching IPA rules. There are no other ways. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] freeIPA 3.3.4 on Centos 6.5
Hello, I am planning to setup IPA-server in centos 6.5 environment to manage user accounts(on ubuntu/centos/redhat) and automount NFS home directories. The IPA-server in centos 6.x repository is 3.0.0. Name: ipa-server Arch: x86_64 Version : 3.0.0 Release : 37.el6 Size: 1.1 M Repo: base Is the latest 3.3.4 version supported in centos 6.5? I would like to hear your opinions before start compiling 3.3.4 from source. Thanks, carl ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] stop alias of https://abc.com/ipa/ui/
Dear sir: where can i set stop alias of /ipa/ui redirection...and let it just use https://abc.com/ipa/ui/ absolute path? thks barry ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeIPA 3.3.4 on Centos 6.5
On Tue, 25 Mar 2014, Carl E. Ma wrote: Hello, I am planning to setup IPA-server in centos 6.5 environment to manage user accounts(on ubuntu/centos/redhat) and automount NFS home directories. The IPA-server in centos 6.x repository is 3.0.0. Name: ipa-server Arch: x86_64 Version : 3.0.0 Release : 37.el6 Size: 1.1 M Repo: base Is the latest 3.3.4 version supported in centos 6.5? I would like to hear your opinions before start compiling 3.3.4 from source. This topic raises regularly. I'd suggest you to read this thread: https://www.redhat.com/archives/freeipa-users/2014-February/msg00255.html -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
