From ssorce at redhat.com Mon Jul 2 14:17:16 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Jul 2007 10:17:16 -0400 Subject: [Freeipa-devel] Re: password change operations slapi plugin In-Reply-To: <1183148743.25772.44.camel@localhost.localdomain> References: <1183148743.25772.44.camel@localhost.localdomain> Message-ID: <1183385836.3567.12.camel@localhost.localdomain> On Fri, 2007-06-29 at 16:25 -0400, Simo Sorce wrote: > Attached the patch with the current code of the password change slapi > plugin > The plugin is still a bit rough, but it works. > See TODOs if you want to help out enhancing it. > The biggest missing feature is thta it does not manage password policies > at all. > We need to define a container and format for these policies and a way to > intercept any change made to them and obey the new policies as soon as > they change. > > That said I think the code is mature enough to be exposes so that others > can start working on it as well. > > If there are no objections I'll push this change into the repository > soon. I am going to commit this, I also renamed all the functions to be ipapwd_* not krb5pwd_* to be consistent. Simo. From ssorce at redhat.com Mon Jul 2 19:51:39 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Jul 2007 15:51:39 -0400 Subject: [Freeipa-devel] Re: password change operations slapi plugin In-Reply-To: <1183385836.3567.12.camel@localhost.localdomain> References: <1183148743.25772.44.camel@localhost.localdomain> <1183385836.3567.12.camel@localhost.localdomain> Message-ID: <1183405899.3567.14.camel@localhost.localdomain> On Mon, 2007-07-02 at 10:17 -0400, Simo Sorce wrote: > On Fri, 2007-06-29 at 16:25 -0400, Simo Sorce wrote: > > Attached the patch with the current code of the password change slapi > > plugin > > The plugin is still a bit rough, but it works. > > See TODOs if you want to help out enhancing it. > > The biggest missing feature is thta it does not manage password policies > > at all. > > We need to define a container and format for these policies and a way to > > intercept any change made to them and obey the new policies as soon as > > they change. > > > > That said I think the code is mature enough to be exposes so that others > > can start working on it as well. > > > > If there are no objections I'll push this change into the repository > > soon. > > I am going to commit this, I also renamed all the functions to be > ipapwd_* not krb5pwd_* to be consistent. Ok I pushed this code in the repo. From ssorce at redhat.com Mon Jul 2 19:54:03 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Jul 2007 15:54:03 -0400 Subject: [Freeipa-devel] cretae a ds user for the fds instance Message-ID: <1183406043.3567.18.camel@localhost.localdomain> The following patch add primarily support to create a system user called ds. This is needed because the data in the directory is sensible and using "nobody" is a no go. The user will also be given access to the kerberos master key (to be able to generate keys in the password extop module). The code to do this is also in the patch but actually not called from anywher ein the code as we need to compile/packetize the plugin first. Simo. From ssorce at redhat.com Mon Jul 2 19:55:03 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 02 Jul 2007 15:55:03 -0400 Subject: [Freeipa-devel] create a ds user for the fds instance In-Reply-To: <1183406043.3567.18.camel@localhost.localdomain> References: <1183406043.3567.18.camel@localhost.localdomain> Message-ID: <1183406103.3567.20.camel@localhost.localdomain> Patch attached ... On Mon, 2007-07-02 at 15:54 -0400, Simo Sorce wrote: > The following patch add primarily support to create a system user called > ds. > This is needed because the data in the directory is sensible and using > "nobody" is a no go. > The user will also be given access to the kerberos master key (to be > able to generate keys in the password extop module). The code to do this > is also in the patch but actually not called from anywher ein the code > as we need to compile/packetize the plugin first. > > Simo. > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa_ds_user.patch Type: text/x-patch Size: 5106 bytes Desc: not available URL: From kmacmill at redhat.com Tue Jul 3 12:45:35 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 03 Jul 2007 08:45:35 -0400 Subject: [Freeipa-devel] patch to add krb instance init In-Reply-To: <1183134005.25772.25.camel@localhost.localdomain> References: <1183134005.25772.25.camel@localhost.localdomain> Message-ID: <1183466735.23369.5.camel@localhost.localdomain> On Fri, 2007-06-29 at 12:20 -0400, Simo Sorce wrote: > The patch contains also a few clean ups. > > If there are no objections I'll do an hg push to commit this stuff to > the main repo, sometimes around 2pm-4pm > > Default DIT is not yet finalized, I'd like comments on that. > Why is there a separate password for kerberos and is it required? > Right now the kadmin is not activcate automatically, that means no way > to add krb principals using kadmin.local or kadmind yet. > I am not sure I want to enable kadmind at all, as it is not able to fill > up an existing user but just crate an independent entry in cn=kerberos. > We need to be able to create service ticket though, so next step will be > to make it possible to use kadmin.local > > To create a user right now you need to add stuff manually using ldif > files and ldapmodify. > This doesn't work for me on either FC7 or rawhide. Seems to hang at: #populate the directory with the realm structure args = ["/usr/kerberos/sbin/kdb5_ldap_util", "-D", "uid=kdc,cn=kerberos,"+self.suffix, "-w", self.kdc_password, "create", "-s", "-r", self.realm_name, "-subtrees", self.suffix, "-sscope", "sub"] run(args) Running manually I get: kdb5_ldap_util: Can't contact LDAP server while initializing database Karl From ssorce at redhat.com Tue Jul 3 14:10:34 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 03 Jul 2007 10:10:34 -0400 Subject: [Freeipa-devel] patch to add krb instance init In-Reply-To: <1183466735.23369.5.camel@localhost.localdomain> References: <1183134005.25772.25.camel@localhost.localdomain> <1183466735.23369.5.camel@localhost.localdomain> Message-ID: <1183471834.15232.4.camel@localhost.localdomain> On Tue, 2007-07-03 at 08:45 -0400, Karl MacMillan wrote: > On Fri, 2007-06-29 at 12:20 -0400, Simo Sorce wrote: > > The patch contains also a few clean ups. > > > > If there are no objections I'll do an hg push to commit this stuff to > > the main repo, sometimes around 2pm-4pm > > > > Default DIT is not yet finalized, I'd like comments on that. > > > > Why is there a separate password for kerberos and is it required? The first password is the ldap Directory Manager password The second password is the KDC Master Password used to generate the KDC Master Key used to encrypt all the keys in the database. You don't want them to be the same (and they would desynchronize easily anyway so it does not really make sense). Actually you should take the KDC Master Key and store it in a locked vault as soon as you are done and forget about it. We could generate it randomly for the user eventually, but this was easier right now. > > Right now the kadmin is not activcate automatically, that means no way > > to add krb principals using kadmin.local or kadmind yet. > > I am not sure I want to enable kadmind at all, as it is not able to fill > > up an existing user but just crate an independent entry in cn=kerberos. > > We need to be able to create service ticket though, so next step will be > > to make it possible to use kadmin.local > > > > To create a user right now you need to add stuff manually using ldif > > files and ldapmodify. > > > > This doesn't work for me on either FC7 or rawhide. Seems to hang at: > > #populate the directory with the realm structure > args = ["/usr/kerberos/sbin/kdb5_ldap_util", "-D", "uid=kdc,cn=kerberos,"+self.suffix, "-w", self.kdc_password, "create", "-s", "-r", self.realm_name, "-subtrees", self.suffix, "-sscope", "sub"] > run(args) > > Running manually I get: > > kdb5_ldap_util: Can't contact LDAP server while initializing database Then you got a problem I guess. Is your fedora-ds instance listening on 127.0.0.1 ? If not why not? SELinux? Iptables? Have you used a real hostname? Or have you made up something random that can't resolve? Simo. From taruishi at redhat.com Tue Jul 3 18:25:10 2007 From: taruishi at redhat.com (Masato Taruishi) Date: Wed, 04 Jul 2007 03:25:10 +0900 Subject: [Freeipa-devel] ipa-cli examples Message-ID: <1183487110.4303.46.camel@x60.taruishi.net> Hi, FreeIPA guys. Sorry about my stupid mail. I'm new to FreeIPA, but instersted in this project. I couldn't find the design detail but I experimentally wrote a simple flexible library to manage LDAP, and others, entries and some tools using the library in this weekend. It's a very quick implementation, poor feature and needs refactoring, but if it's useful for this project, I'd like to contribute these tools. Summary: ========= - flexible LDAP management library in python including * PasswordModifyExtension support * PagedResultsControl support - example command line tools * ipa-useradd Add a user to LDAP like /usr/sbin/useradd * ipa-userdel Delete a user from LDAP like /usr/sbin/userdel * ipa-vipw Edit user database in LDAP like /usr/sbin/vipw * ipa-passwd Change user password in LDAP by using Password Modify Extension How To Use: ============= 1. Install python-ldap ~# yum install python-ldap 2. Unpack ipa-cli-taru.tar.gz ~$ tar zxf ipa-cli-taru.tar.gz 3. Change directory ~$ cd ipa-cli/src 4. Add user ~$ ./ipa-useradd -H ldap://localhost/dc=example,dc=com \ -D 'cn=Directory Manager' -w user1 5. Edit user ~$ ./ipa-vipw -H ldap://localhost/dc=example,dc=com???objectClass=posixAccount \ -D 'cn=Directory Manager' -w 6. Change password ~$ ./ipa-passwd -H ldap://localhost/dc=example,dc=com \ -D 'cn=Directory Manager' -w -Z user1 Old password: New password: New password(again): 7. Remove user ~$ ./ipa-userdel -H ldap://localhost/dc=example,dc=com \ -D 'cn=Directory Manager' -w user1 The following README file can be found in the attached tarball, but you can read the document here before unpacking the tarball. I hope this work will help this project. Best regards. ==================== REAMDE in tarball ==================== Required packages: python-ldap Overview ======== This directory contains a library to manage LDAP entries and command line tools using the library. Currently, the following experimental command line tools are provided: * ipa-useradd Add a user to LDAP with similar interfaces to /usr/sbin/useradd * ipa-userdel Delete a user from LDAP with similar interfaces to /usr/sbin/userdel * ipa-vipw Edit user database in LDAP with similar interfaces to /usr/sbin/vipw * ipa-passwd Change user password in LDAP by using Password Modify Extension ipa-useradd ----------- 'ipa-useradd' easily adds a new user to LDAP. Example ~$ ipa-useradd -H ldap://localhost/ou=users,dc=example,dc=com \ -D 'cn=Directory Manager' -w secret user1 Usage: usage: ipa-useradd [options] LOGIN options: -h, --help show this help message and exit -H URL, --url=URL LDAP url -D BINDDN, --binddn=BINDDN bind DN -w BINDPW, --bindpw=BINDPW bind password --config=CONFIG config file -S SECTION, --section=SECTION use SECTION for user account container -Z Start TLS request for LDAP connection -d HOME_DIR, --home-dir=HOME_DIR home directory for the new user account -c COMMENT, --comment=COMMENT set the GECOS field for the new user account -g GROUP, --gid=GROUP force use GROUP for the new user account -p PASSWORD, --password=PASSWORD use encrypted password for the new user account -s SHELL, --shell=SHELL the login shell for the new user account -u UID, --uid=UID force use the UID for the new user account ipa-userdel ----------- 'ipa-usedel' easily deletes a user from LDAP. Example ~$ ipa-userdel -H ldap://localhost/ou=users,dc=example,dc=com \ -D 'cn=Directory Manager' -w secret user1 Usage usage: ipa-userdel [options] LOGIN options: -h, --help show this help message and exit -H URL, --url=URL LDAP url -D BINDDN, --binddn=BINDDN bind DN -w BINDPW, --bindpw=BINDPW bind password --config=CONFIG config file -S SECTION, --section=SECTION use SECTION for user account container -Z Start TLS request for LDAP connection ipa-vipw -------- 'ipa-vipw' creates a /etc/passwd-like file by using LDAP in order to edit LDAP users easily. Example ~$ ipa-vipw \ -H ldap://localhost/ou=users,dc=example,dc=com???objectClass=posixAccount \ -D 'cn=Directory Manager' -w secret Usage usage: ipa-vipw [options] options: -h, --help show this help message and exit -H URL, --url=URL LDAP url -D BINDDN, --binddn=BINDDN bind DN -w BINDPW, --bindpw=BINDPW bind password --config=CONFIG config file -S SECTION, --section=SECTION use SECTION for user account container -s SCOPE, --scope=SCOPE LDAP search scope: one of 'one' or 'sub' -C COLUMNS, --columns=COLUMNS list of colums -Z Start TLS request for LDAP connection ipa-passwd ---------- 'ipa-passwd' asks old password and new password twice and change the user password in LDAP by using LDAP Password Modify Extension. If you bind as rootdn, then you don't have to input 'Old password: ' and just press enter. Example ~$ ipa-passwd \ -H ldap://localhost/ou=users,dc=example,dc=com \ -D 'cn=Directory Manager' -w secret -Z user1 Old password: New password: New password(again): Usage usage: ipa-passwd [options] [LOGIN] options: -h, --help show this help message and exit -H URL, --url=URL LDAP url -D BINDDN, --binddn=BINDDN bind DN -w BINDPW, --bindpw=BINDPW bind password --config=CONFIG config file -S SECTION, --section=SECTION use SECTION for user account container -Z Start TLS request for LDAP connection Configuration ============= You can use configuration file to define your database in order to reduce command line arguments. The format of the configuration file follows python general configuration format such as: [section] option = value option2 = value2 ... Example: [user] url = ldap://localhost/ou=users,dc=example,dc=com???objectClass=posixAccount dn = cn=Directory Manager password = secret If you create the above configration to the file 'ipa.cf', then the proper command would be: ~$ ipa-useradd --config ipa.cf -S user user1 ~$ ipa-userdel --config ipa.cf -S user user1 ~$ ipa-vipw --config ipa.cf -S user Supported Options ----------------- The following options are supported: url = ldap://localhost/ The LDAP URL of this container. BNF definition of LDAP URL. hostport host:port dn distinguished name attributes list with attributes scope search scope string filter LDAP search filter ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attrs] ["?" [scope] ["?" [filter] ["?" extensions]]]]]] You can attributes, scope, filter terminal to specify these values rather than using 'attrs', 'scope', 'filterstr' options below. These values are ignored if you use the options. are currently not used. attrs = cn,uid,ou Attribute List separated by comma filterstr = objectClass=person LDAP Filter String scope = one|sub LDAP Search Scope auehmethod = anonymous|simple LDAP BIND method, anonymous bind or simple bind dn = cn=Directory Manager BINDDN for simple bind password = a BINDPW for simple bind debug = true Turn on debugging for this container page_size = 10 Size of Page for LDAP PagedResultControl tls = true Enable StartTLS extension -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-cli-taru.tar.gz Type: application/x-compressed-tar Size: 11858 bytes Desc: not available URL: From jfenal at redhat.com Tue Jul 3 18:50:32 2007 From: jfenal at redhat.com (Jerome Fenal) Date: Tue, 03 Jul 2007 20:50:32 +0200 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183487110.4303.46.camel@x60.taruishi.net> References: <1183487110.4303.46.camel@x60.taruishi.net> Message-ID: <1183488632.20591.35.camel@localhost.localdomain> Le mercredi 04 juillet 2007 ? 03:25 +0900, Masato Taruishi a ?crit : > Hi, FreeIPA guys. Hi all, > Sorry about my stupid mail. I'm new to FreeIPA, but > instersted in this project. > > I couldn't find the design detail but I experimentally > wrote a simple flexible library to manage LDAP, and others, > entries and some tools using the library in this weekend. > It's a very quick implementation, poor feature and needs > refactoring, but if it's useful for this project, I'd like > to contribute these tools. Hey this is interesting, even standalone. Interestingly enough, I was also trying on my (too few) spare time the same (but with a language I know, Perl). You can see my quick start on http://search.cpan.org/dist/POSIX-Account-LDAP/ Maybe it would be interesting to share ideas around the configuration file, as it seems we have quite the same approach. I even have a test suite in it, that may be shared with other projects and used also to assess coverage of the code. Regards, J. -- J?r?me Fenal, RHCE Tel.: +33 1 4191 2342 Service delivery manager Mob.: +33 6 8806 5115 Global Professional Services Fax.: +33 1 4191 2332 http://www.redhat.fr/ jfenal at redhat.com Red Hat France SARL Siret n? 421 199 464 00056 171, avenue Georges Cl?menceau 92024 Nanterre Cedex SOA : Red Hat est le moyen Simple, Ouvert et Abordable pour moderniser votre infrastructure IT traditionnelle From kmacmill at redhat.com Tue Jul 3 19:01:06 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 03 Jul 2007 15:01:06 -0400 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183487110.4303.46.camel@x60.taruishi.net> References: <1183487110.4303.46.camel@x60.taruishi.net> Message-ID: <1183489266.18395.17.camel@localhost.localdomain> On Wed, 2007-07-04 at 03:25 +0900, Masato Taruishi wrote: > Hi, FreeIPA guys. > > Sorry about my stupid mail. I'm new to FreeIPA, but > instersted in this project. > > I couldn't find the design detail but I experimentally > wrote a simple flexible library to manage LDAP, and others, > entries and some tools using the library in this weekend. > It's a very quick implementation, poor feature and needs > refactoring, but if it's useful for this project, I'd like > to contribute these tools. Thanks - looks interesting. We'll try to post some more design information as we go. Comments below. > Summary: > ========= > > - flexible LDAP management library in python including > > * PasswordModifyExtension support > * PagedResultsControl support > I think we have the same goals, but I just want to mention that with freeipa we are trying to hide as many ldap details as possible. I know that this is just a backend component, but I wanted to make that goal explicit. > - example command line tools > > * ipa-useradd > > Add a user to LDAP like /usr/sbin/useradd > How do you select the object class to represent the user? > * ipa-userdel > > Delete a user from LDAP like /usr/sbin/userdel > > * ipa-vipw > > Edit user database in LDAP like /usr/sbin/vipw > So this creates a temporary file similar to the password file for interactive editing? > * ipa-passwd > > Change user password in LDAP by using Password > Modify Extension > > How To Use: > ============= > > 1. Install python-ldap > > ~# yum install python-ldap > > 2. Unpack ipa-cli-taru.tar.gz > > ~$ tar zxf ipa-cli-taru.tar.gz > > 3. Change directory > > ~$ cd ipa-cli/src > > 4. Add user > > ~$ ./ipa-useradd -H ldap://localhost/dc=example,dc=com \ > -D 'cn=Directory Manager' -w user1 > We are planning to use service discovery most of the time to avoid passing host and base dn. Also we'd prefer to always use kerberos instead of simple binds. Karl From taruishi at redhat.com Wed Jul 4 05:12:11 2007 From: taruishi at redhat.com (Masato Taruishi) Date: Wed, 04 Jul 2007 14:12:11 +0900 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183488632.20591.35.camel@localhost.localdomain> References: <1183487110.4303.46.camel@x60.taruishi.net> <1183488632.20591.35.camel@localhost.localdomain> Message-ID: <1183525931.5476.7.camel@x60.taruishi.net> > Le mercredi 04 juillet 2007 ? 03:25 +0900, Masato Taruishi a ?crit : > > Hi, FreeIPA guys. > > Hi all, > > > Sorry about my stupid mail. I'm new to FreeIPA, but > > instersted in this project. > > > > I couldn't find the design detail but I experimentally > > wrote a simple flexible library to manage LDAP, and others, > > entries and some tools using the library in this weekend. > > It's a very quick implementation, poor feature and needs > > refactoring, but if it's useful for this project, I'd like > > to contribute these tools. > > Hey this is interesting, even standalone. > Interestingly enough, I was also trying on my (too few) spare time the > same (but with a language I know, Perl). > You can see my quick start on > http://search.cpan.org/dist/POSIX-Account-LDAP/ > > Maybe it would be interesting to share ideas around the configuration > file, as it seems we have quite the same approach. > > I even have a test suite in it, that may be shared with other projects > and used also to assess coverage of the code. Thanks. I'll look into it, but basically my library doesn't depend on LDAP itself by abstracting user account information. So you can use my tool to manage /etc/passwd, though I need to implement /etc/passwd backend. I've written the similar library few years ago, which supports many backends such as LDAP, CSV, pwd, /etc/passwd and so on. I'm just rewriting the same infrastracture from scracth with some design improvements which the previous library doesn't support. Anyway, thanks for your information. > Regards, > > J. From taruishi at redhat.com Wed Jul 4 05:42:55 2007 From: taruishi at redhat.com (Masato Taruishi) Date: Wed, 04 Jul 2007 14:42:55 +0900 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183489266.18395.17.camel@localhost.localdomain> References: <1183487110.4303.46.camel@x60.taruishi.net> <1183489266.18395.17.camel@localhost.localdomain> Message-ID: <1183527775.5476.38.camel@x60.taruishi.net> > On Wed, 2007-07-04 at 03:25 +0900, Masato Taruishi wrote: > > Hi, FreeIPA guys. > > > > Sorry about my stupid mail. I'm new to FreeIPA, but > > instersted in this project. > > > > I couldn't find the design detail but I experimentally > > wrote a simple flexible library to manage LDAP, and others, > > entries and some tools using the library in this weekend. > > It's a very quick implementation, poor feature and needs > > refactoring, but if it's useful for this project, I'd like > > to contribute these tools. > > Thanks - looks interesting. We'll try to post some more design > information as we go. Comments below. > > > Summary: > > ========= > > > > - flexible LDAP management library in python including > > > > * PasswordModifyExtension support > > * PagedResultsControl support > > > > I think we have the same goals, but I just want to mention that with > freeipa we are trying to hide as many ldap details as possible. I know > that this is just a backend component, but I wanted to make that goal > explicit. Exactly. The above library provides database abstraction which hides ldap details by creating abstract class to hold user account informations. PasswordModifyExtension is used only in the ldap backend, so you don't have to consider about ldap details as long as you use this library. The ldap backend uses Password Modify Extension internally, in order to communicate with ipa-pwd-extop SLAPI plugin. In addition, becuase of database abstraction, you can use another user account database backend such as /etc/passwd, CSV and so on instead of ldap, though these backend has to be written in the future. > > - example command line tools > > > > * ipa-useradd > > > > Add a user to LDAP like /usr/sbin/useradd > > > > How do you select the object class to represent the user? Good question. At least in the current implementation, the object classes are hard-coded now :( It has to be configurable. I've written the similar library a few years ago and the library provides template-based default objectclass determination. Because account informations created by template don't depend on LDAP itself, so The 'Mapping Tier' maps the abstract informations to LDAP specific atrributes as follows: +----------+ +---------------------+ |Template+--+->|Abstract User Info| +----------+ | +-+-------------------+ | | uid ------+ | +------+ +------+ +---------+ +-->|Mapper+->|LDAPBE+->|Fedora-DS| +-------+ +-------+ +-----------+ I want to reimplement most useful features, which the previous library has, with some improvements. The new library is in really really early stage. I wrote code this in last sunday so it needs more time to refine it. > > * ipa-userdel > > > > Delete a user from LDAP like /usr/sbin/userdel > > > > * ipa-vipw > > > > Edit user database in LDAP like /usr/sbin/vipw > > > > So this creates a temporary file similar to the password file for > interactive editing? Yes. ipa-vipw doesn't provide any lock mechanism to LDAP. > > * ipa-passwd > > > > Change user password in LDAP by using Password > > Modify Extension > > > > How To Use: > > ============= > > > > 1. Install python-ldap > > > > ~# yum install python-ldap > > > > 2. Unpack ipa-cli-taru.tar.gz > > > > ~$ tar zxf ipa-cli-taru.tar.gz > > > > 3. Change directory > > > > ~$ cd ipa-cli/src > > > > 4. Add user > > > > ~$ ./ipa-useradd -H ldap://localhost/dc=example,dc=com \ > > -D 'cn=Directory Manager' -w user1 > > > > We are planning to use service discovery most of the time to avoid > passing host and base dn. Also we'd prefer to always use kerberos > instead of simple binds. I agreed. The library also abstracts authentication method so that it can support additional authentications such as SASL/Diest-MD5 , GSSAPI and so on. It has already supported anonymous bind and simple bind. SASL bind also has to be supported, of cource. Thanks From ssorce at redhat.com Wed Jul 4 12:46:26 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 04 Jul 2007 08:46:26 -0400 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183527775.5476.38.camel@x60.taruishi.net> References: <1183487110.4303.46.camel@x60.taruishi.net> <1183489266.18395.17.camel@localhost.localdomain> <1183527775.5476.38.camel@x60.taruishi.net> Message-ID: <1183553186.16302.25.camel@localhost.localdomain> On Wed, 2007-07-04 at 14:42 +0900, Masato Taruishi wrote: > Exactly. The above library provides database abstraction which hides > ldap details by creating abstract class to hold user account > informations. PasswordModifyExtension is used only in the ldap > backend, so you don't have to consider about ldap details as long as > you use this library. The ldap backend uses Password Modify Extension > internally, in order to communicate with ipa-pwd-extop SLAPI plugin. Our problem is that we want to hide some details, true, but we also definitively want a much richer interface to set more than just the fields in passwd (or passwd+shadow). > In addition, becuase of database abstraction, you can use another > user account database backend such as /etc/passwd, CSV and so on > instead of ldap, though these backend has to be written in the > future. In which way would this be different from libuser? > > > - example command line tools > > > > > > * ipa-useradd > > > > > > Add a user to LDAP like /usr/sbin/useradd > > > > > > > How do you select the object class to represent the user? > > Good question. At least in the current implementation, the > object classes are hard-coded now :( It has to be configurable. We were thinking of putting templates directly in ldap, so that they can centrally managed and downloaded at run time. Simo. From taruishi at redhat.com Thu Jul 5 04:57:12 2007 From: taruishi at redhat.com (Masato Taruishi) Date: Thu, 05 Jul 2007 13:57:12 +0900 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183553186.16302.25.camel@localhost.localdomain> References: <1183487110.4303.46.camel@x60.taruishi.net> <1183489266.18395.17.camel@localhost.localdomain> <1183527775.5476.38.camel@x60.taruishi.net> <1183553186.16302.25.camel@localhost.localdomain> Message-ID: <1183611432.4503.73.camel@x60.taruishi.net> > > Exactly. The above library provides database abstraction which hides > > ldap details by creating abstract class to hold user account > > informations. PasswordModifyExtension is used only in the ldap > > backend, so you don't have to consider about ldap details as long as > > you use this library. The ldap backend uses Password Modify Extension > > internally, in order to communicate with ipa-pwd-extop SLAPI plugin. > > Our problem is that we want to hide some details, true, but we also > definitively want a much richer interface to set more than just the > fields in passwd (or passwd+shadow). Of cource, the library supports the above requirement. > > In addition, becuase of database abstraction, you can use another > > user account database backend such as /etc/passwd, CSV and so on > > instead of ldap, though these backend has to be written in the > > future. > > In which way would this be different from libuser? Are you planning that you'll use libuser for ipa-cli tools? I'm glad that my post became the starting point to discuss about the admin detail. Basically, libuser and the library provides almost the same features and tries to solve the same problem. One big difference is that the library can manage tree and forest structure, but it's not so important because you can implement the feature to libuser, too. In addition to the current implementation, the design of this library is based on one of my previous implementation, which supports many features including: * Daily migration/synchronization between any kind of backends You can edit /etc/passwd and synchronize ldap entries with it any time, while migrationtools only supports the first time migration. You can also synchronize /etc/passwd with ldap enetries. * Event listener Any number of listeners can be called for each event. For example, mkhomedir listener creates the user's homedirectory when the user is created on ldap. This previous library also supports LDAP Content Synchronization, rfc4533, to call listeners when the ldap server is changed by another clients. I used this feature to separate an admin server and a file server. This library has many other features, but I don't know how many features FreeIPA requires, and these features also can be implemented in libuser if needed. > > > > - example command line tools > > > > > > > > * ipa-useradd > > > > > > > > Add a user to LDAP like /usr/sbin/useradd > > > > > > > > > > How do you select the object class to represent the user? > > > > Good question. At least in the current implementation, the > > object classes are hard-coded now :( It has to be configurable. > > We were thinking of putting templates directly in ldap, so that they can > centrally managed and downloaded at run time. The previous library also manages configuration as entry so that configuration can be stored in any kind of backend. -- Masato Taruishi From ssorce at redhat.com Thu Jul 5 13:11:35 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 05 Jul 2007 09:11:35 -0400 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183611432.4503.73.camel@x60.taruishi.net> References: <1183487110.4303.46.camel@x60.taruishi.net> <1183489266.18395.17.camel@localhost.localdomain> <1183527775.5476.38.camel@x60.taruishi.net> <1183553186.16302.25.camel@localhost.localdomain> <1183611432.4503.73.camel@x60.taruishi.net> Message-ID: <1183641095.26378.3.camel@localhost.localdomain> On Thu, 2007-07-05 at 13:57 +0900, Masato Taruishi wrote: > Are you planning that you'll use libuser for ipa-cli tools? NO, not at this point at least. > I'm glad that my post became the starting point to discuss about > the admin detail. Basically, libuser and the library provides > almost the same features and tries to solve the same problem. > > One big difference is that the library can manage tree > and forest structure, but it's not so important because you > can implement the feature to libuser, too. > > In addition to the current implementation, the design of this > library is based on one of my previous implementation, which > supports many features including: > > * Daily migration/synchronization between any kind of > backends > > You can edit /etc/passwd and synchronize ldap entries > with it any time, while migrationtools only supports > the first time migration. You can also synchronize > /etc/passwd with ldap enetries. > > * Event listener > > Any number of listeners can be called for each > event. For example, mkhomedir listener creates > the user's homedirectory when the user is created > on ldap. This previous library also supports LDAP > Content Synchronization, rfc4533, to call listeners > when the ldap server is changed by another clients. > I used this feature to separate an admin server and > a file server. > > This library has many other features, but I don't know > how many features FreeIPA requires, and these features > also can be implemented in libuser if needed. So where is this "previous" library? :) Simo. From taruishi at redhat.com Fri Jul 6 10:51:12 2007 From: taruishi at redhat.com (Masato Taruishi) Date: Fri, 06 Jul 2007 19:51:12 +0900 Subject: [Freeipa-devel] ipa-cli examples In-Reply-To: <1183641095.26378.3.camel@localhost.localdomain> References: <1183487110.4303.46.camel@x60.taruishi.net> <1183489266.18395.17.camel@localhost.localdomain> <1183527775.5476.38.camel@x60.taruishi.net> <1183553186.16302.25.camel@localhost.localdomain> <1183611432.4503.73.camel@x60.taruishi.net> <1183641095.26378.3.camel@localhost.localdomain> Message-ID: <1183719072.4621.2.camel@x60.taruishi.net> > On Thu, 2007-07-05 at 13:57 +0900, Masato Taruishi wrote: > > > Are you planning that you'll use libuser for ipa-cli tools? > > NO, not at this point at least. > > > I'm glad that my post became the starting point to discuss about > > the admin detail. Basically, libuser and the library provides > > almost the same features and tries to solve the same problem. > > > > One big difference is that the library can manage tree > > and forest structure, but it's not so important because you > > can implement the feature to libuser, too. One more thing, libuser doesn't support 'search'. > > In addition to the current implementation, the design of this > > library is based on one of my previous implementation, which > > supports many features including: > > > > * Daily migration/synchronization between any kind of > > backends > > > > You can edit /etc/passwd and synchronize ldap entries > > with it any time, while migrationtools only supports > > the first time migration. You can also synchronize > > /etc/passwd with ldap enetries. > > > > * Event listener > > > > Any number of listeners can be called for each > > event. For example, mkhomedir listener creates > > the user's homedirectory when the user is created > > on ldap. This previous library also supports LDAP > > Content Synchronization, rfc4533, to call listeners > > when the ldap server is changed by another clients. > > I used this feature to separate an admin server and > > a file server. > > > > This library has many other features, but I don't know > > how many features FreeIPA requires, and these features > > also can be implemented in libuser if needed. > > So where is this "previous" library? :) Ah, sorry. I forgot to say that it's not open. That's why I rewrote a new library. From rcritten at redhat.com Tue Jul 10 21:11:22 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Jul 2007 17:11:22 -0400 Subject: [Freeipa-devel] SSL Message-ID: <4693F5FA.1060803@redhat.com> So I was thinking about the XML-RPC portion of this. One thing we'll be doing is setting and resetting user passwords. So we should use SSL to protect them, if for no other reaosn. So: 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings I couldn't find them. OLPC may do this work for us (http://dev.laptop.org/ticket/855) 2. How will we manage trust between the gui and command-line clients and XML-RPC server? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Tue Jul 10 21:29:29 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 10 Jul 2007 17:29:29 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <4693F5FA.1060803@redhat.com> References: <4693F5FA.1060803@redhat.com> Message-ID: <1184102969.9377.0.camel@localhost.localdomain> On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: > So I was thinking about the XML-RPC portion of this. > > One thing we'll be doing is setting and resetting user passwords. So we > should use SSL to protect them, if for no other reaosn. > > So: > > 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings > I couldn't find them. OLPC may do this work for us > (http://dev.laptop.org/ticket/855) > > 2. How will we manage trust between the gui and command-line clients and > XML-RPC server? IF we are going to use kerberos, can't we just use GSSAPI to encrypt traffic? Simo. From prowley at redhat.com Tue Jul 10 21:56:34 2007 From: prowley at redhat.com (Pete Rowley) Date: Tue, 10 Jul 2007 14:56:34 -0700 Subject: [Freeipa-devel] SSL In-Reply-To: <4693F5FA.1060803@redhat.com> References: <4693F5FA.1060803@redhat.com> Message-ID: <46940092.9070002@redhat.com> Rob Crittenden wrote: > So I was thinking about the XML-RPC portion of this. > > One thing we'll be doing is setting and resetting user passwords. So > we should use SSL to protect them, if for no other reaosn. > > So: > > 1. I assume we'll have to use OpenSSL. If there are Python NSS > bindings I couldn't find them. OLPC may do this work for us > (http://dev.laptop.org/ticket/855) > Python NSS is a high priority, Bob Relyea should be able to help there. Though we could use GSSAPI for encryption assuming adequate python support. > 2. How will we manage trust between the gui and command-line clients > and XML-RPC server? -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jul 11 14:20:30 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Jul 2007 10:20:30 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184102969.9377.0.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> Message-ID: <4694E72E.9000105@redhat.com> Simo Sorce wrote: > On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: >> So I was thinking about the XML-RPC portion of this. >> >> One thing we'll be doing is setting and resetting user passwords. So we >> should use SSL to protect them, if for no other reaosn. >> >> So: >> >> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings >> I couldn't find them. OLPC may do this work for us >> (http://dev.laptop.org/ticket/855) >> >> 2. How will we manage trust between the gui and command-line clients and >> XML-RPC server? > > IF we are going to use kerberos, can't we just use GSSAPI to encrypt > traffic? > > Simo. > There is a python-krbV package available in Fedora which is described as "a relatively thin wrapper around the underlying C API." Can someone more knowledgable take a look and see if this will fit our needs? It is greek to me. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jul 11 14:44:12 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 11 Jul 2007 10:44:12 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <4694E72E.9000105@redhat.com> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <4694E72E.9000105@redhat.com> Message-ID: <1184165052.9377.17.camel@localhost.localdomain> On Wed, 2007-07-11 at 10:20 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: > >> So I was thinking about the XML-RPC portion of this. > >> > >> One thing we'll be doing is setting and resetting user passwords. So we > >> should use SSL to protect them, if for no other reaosn. > >> > >> So: > >> > >> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings > >> I couldn't find them. OLPC may do this work for us > >> (http://dev.laptop.org/ticket/855) > >> > >> 2. How will we manage trust between the gui and command-line clients and > >> XML-RPC server? > > > > IF we are going to use kerberos, can't we just use GSSAPI to encrypt > > traffic? > > > > Simo. > > > > There is a python-krbV package available in Fedora which is described as > "a relatively thin wrapper around the underlying C API." > > Can someone more knowledgable take a look and see if this will fit our > needs? It is greek to me. http://people.redhat.com/mikeb/python-krbV/ Maybe you can ask Mike? :-) Simo. From kmacmill at redhat.com Wed Jul 11 19:47:57 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 11 Jul 2007 15:47:57 -0400 Subject: [Freeipa-devel] Architecture diagram Message-ID: <1184183277.31248.10.camel@localhost.localdomain> I put up the start of some notes on the architecture - including a diagram - at http://freeipa.com/page/IpaArchitectureV1. What besides the toplevel diagram is needed? Other comments? Karl From ssorce at redhat.com Wed Jul 11 19:53:20 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 11 Jul 2007 15:53:20 -0400 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184183277.31248.10.camel@localhost.localdomain> References: <1184183277.31248.10.camel@localhost.localdomain> Message-ID: <1184183600.9377.19.camel@localhost.localdomain> On Wed, 2007-07-11 at 15:47 -0400, Karl MacMillan wrote: > I put up the start of some notes on the architecture - including a > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > What besides the toplevel diagram is needed? Other comments? Very nice, maybe we should change the underlying Fedora, with Operating System ? or do we really want to tie it to fedora? Simo. From prowley at redhat.com Wed Jul 11 20:02:35 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 11 Jul 2007 13:02:35 -0700 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184183277.31248.10.camel@localhost.localdomain> References: <1184183277.31248.10.camel@localhost.localdomain> Message-ID: <4695375B.3060003@redhat.com> Karl MacMillan wrote: > I put up the start of some notes on the architecture - including a > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > What besides the toplevel diagram is needed? Other comments? > Looks good, however it would be good to show that everything plugs into DS, so in this kind of arch diagram I guess it would be shown as a layer between OS and the other services. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Wed Jul 11 20:04:02 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 11 Jul 2007 16:04:02 -0400 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184183600.9377.19.camel@localhost.localdomain> References: <1184183277.31248.10.camel@localhost.localdomain> <1184183600.9377.19.camel@localhost.localdomain> Message-ID: <1184184242.31248.13.camel@localhost.localdomain> On Wed, 2007-07-11 at 15:53 -0400, Simo Sorce wrote: > On Wed, 2007-07-11 at 15:47 -0400, Karl MacMillan wrote: > > I put up the start of some notes on the architecture - including a > > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > > > What besides the toplevel diagram is needed? Other comments? > > Very nice, maybe we should change the underlying Fedora, with Operating > System ? or do we really want to tie it to fedora? > I debated that - on the one hand we aren't doing anything particularly Fedora specific (and shouldn't), but we aren't specifically testing portability. I was afraid of promising too much. I guess I'll change it to linux instead (operating system is too generic I think). Karl > Simo. > From ssorce at redhat.com Wed Jul 11 20:18:45 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 11 Jul 2007 16:18:45 -0400 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184184242.31248.13.camel@localhost.localdomain> References: <1184183277.31248.10.camel@localhost.localdomain> <1184183600.9377.19.camel@localhost.localdomain> <1184184242.31248.13.camel@localhost.localdomain> Message-ID: <1184185125.9377.21.camel@localhost.localdomain> On Wed, 2007-07-11 at 16:04 -0400, Karl MacMillan wrote: > On Wed, 2007-07-11 at 15:53 -0400, Simo Sorce wrote: > > On Wed, 2007-07-11 at 15:47 -0400, Karl MacMillan wrote: > > > I put up the start of some notes on the architecture - including a > > > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > > > > > What besides the toplevel diagram is needed? Other comments? > > > > Very nice, maybe we should change the underlying Fedora, with Operating > > System ? or do we really want to tie it to fedora? > > > > I debated that - on the one hand we aren't doing anything particularly > Fedora specific (and shouldn't), but we aren't specifically testing > portability. I was afraid of promising too much. > > I guess I'll change it to linux instead (operating system is too generic > I think). Well in theory nobody will make it impossible to port this stuff on say OpenSolaris :-) Linux seem reductive to me even if we really will not test anything but RHEL/Fedora right now. Simo. From kmacmill at redhat.com Wed Jul 11 20:30:59 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Wed, 11 Jul 2007 16:30:59 -0400 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <4695375B.3060003@redhat.com> References: <1184183277.31248.10.camel@localhost.localdomain> <4695375B.3060003@redhat.com> Message-ID: <1184185859.31248.16.camel@localhost.localdomain> On Wed, 2007-07-11 at 13:02 -0700, Pete Rowley wrote: > Karl MacMillan wrote: > > I put up the start of some notes on the architecture - including a > > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > > > What besides the toplevel diagram is needed? Other comments? > > > Looks good, however it would be good to show that everything plugs into > DS, so in this kind of arch diagram I guess it would be shown as a layer > between OS and the other services. > That's what the lines at the bottom were supposed to show - I guess I don't see it as a layer, just a data store. Maybe the lines need to be more prominent? Karl From prowley at redhat.com Wed Jul 11 20:58:08 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 11 Jul 2007 13:58:08 -0700 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184185859.31248.16.camel@localhost.localdomain> References: <1184183277.31248.10.camel@localhost.localdomain> <4695375B.3060003@redhat.com> <1184185859.31248.16.camel@localhost.localdomain> Message-ID: <46954460.6000906@redhat.com> Karl MacMillan wrote: > On Wed, 2007-07-11 at 13:02 -0700, Pete Rowley wrote: > >> Karl MacMillan wrote: >> >>> I put up the start of some notes on the architecture - including a >>> diagram - at http://freeipa.com/page/IpaArchitectureV1. >>> >>> What besides the toplevel diagram is needed? Other comments? >>> >>> >> Looks good, however it would be good to show that everything plugs into >> DS, so in this kind of arch diagram I guess it would be shown as a layer >> between OS and the other services. >> >> > > That's what the lines at the bottom were supposed to show - I guess I > don't see it as a layer, just a data store. Maybe the lines need to be > more prominent? > > It looks to me like all of the services are connected somehow and tied to the OS, but I think you'd have to make some guesses that all the other services actually used the DS. Maybe a directional arrow would suffice. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Wed Jul 11 21:53:02 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 11 Jul 2007 14:53:02 -0700 Subject: [Freeipa-devel] First cut of schema doc Message-ID: <4695513E.8060001@redhat.com> Getting something up to argue over :) http://freeipa.com/page/SchemaV1 -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Wed Jul 11 22:07:44 2007 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 11 Jul 2007 18:07:44 -0400 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <4695513E.8060001@redhat.com> References: <4695513E.8060001@redhat.com> Message-ID: <1184191664.9377.25.camel@localhost.localdomain> On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > Getting something up to argue over :) > > http://freeipa.com/page/SchemaV1 Questions and remarks: - what is/why dc=com ? - I removed uniqueidentifier: IPA for now, as it is redundant (info: IPa v1.0 is enough) - more info on objcetcalss: ipaRealm ? Why do we need it ? The exp-lanation on the page is not really clear to me. Simo. From prowley at redhat.com Wed Jul 11 22:23:26 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 11 Jul 2007 15:23:26 -0700 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184191664.9377.25.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> Message-ID: <4695585E.9070707@redhat.com> Simo Sorce wrote: > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > >> Getting something up to argue over :) >> >> http://freeipa.com/page/SchemaV1 >> > > Questions and remarks: > - what is/why dc=com ? > could be dc=org or whatever that component of the realm name is. The important thing is the splitting off of the most significant portion of the realm name from the suffix to be part of DIT (replacing cn=default which we didn't like) > - I removed uniqueidentifier: IPA for now, as it is redundant (info: IPa > v1.0 is enough) > I don't think clients should have to parse the string in any fashion other than compare in order to be sure this is an IPA server. > - more info on objcetcalss: ipaRealm ? Why do we need it ? The > exp-lanation on the page is not really clear to me. > > OK I'll re-word it - it's discovery, since we have this partitioned off into a separate space so that clients can search through only the things they are interested in I thought it would be a good idea to be able to discover where that place is. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Wed Jul 11 22:43:15 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 12 Jul 2007 08:43:15 +1000 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <4695585E.9070707@redhat.com> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> Message-ID: <1184193795.2838.153.camel@localhost.localdomain> On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > Simo Sorce wrote: > > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > > > >> Getting something up to argue over :) > >> > >> http://freeipa.com/page/SchemaV1 > >> > > > > Questions and remarks: > > - what is/why dc=com ? > > > could be dc=org or whatever that component of the realm name is. The > important thing is the splitting off of the most significant portion of > the realm name from the suffix to be part of DIT (replacing cn=default > which we didn't like) Doesn't that break referrals to other DIT trees that may hold other parts of the data? > > - I removed uniqueidentifier: IPA for now, as it is redundant (info: IPa > > v1.0 is enough) > > > I don't think clients should have to parse the string in any fashion > other than compare in order to be sure this is an IPA server. > > - more info on objcetcalss: ipaRealm ? Why do we need it ? The > > exp-lanation on the page is not really clear to me. > > > > > OK I'll re-word it - it's discovery, since we have this partitioned off > into a separate space so that clients can search through only the things > they are interested in I thought it would be a good idea to be able to > discover where that place is. Could this be in the rootDSE? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From prowley at redhat.com Wed Jul 11 22:50:47 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 11 Jul 2007 15:50:47 -0700 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184193795.2838.153.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184193795.2838.153.camel@localhost.localdomain> Message-ID: <46955EC7.3030102@redhat.com> Andrew Bartlett wrote: > On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > >> Simo Sorce wrote: >> >>> On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: >>> >>> >>>> Getting something up to argue over :) >>>> >>>> http://freeipa.com/page/SchemaV1 >>>> >>>> >>> Questions and remarks: >>> - what is/why dc=com ? >>> >>> >> could be dc=org or whatever that component of the realm name is. The >> important thing is the splitting off of the most significant portion of >> the realm name from the suffix to be part of DIT (replacing cn=default >> which we didn't like) >> > > Doesn't that break referrals to other DIT trees that may hold other > parts of the data? > I don't think so, but then I don't think we are going to support such a model. >> >> OK I'll re-word it - it's discovery, since we have this partitioned off >> into a separate space so that clients can search through only the things >> they are interested in I thought it would be a good idea to be able to >> discover where that place is. >> > > Could this be in the rootDSE? > That was my first thought too, but I don't think we can modify that. We actually have info you might put into rootDSE placed in the suffix entry. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Wed Jul 11 22:55:41 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 12 Jul 2007 08:55:41 +1000 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <46955EC7.3030102@redhat.com> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184193795.2838.153.camel@localhost.localdomain> <46955EC7.3030102@redhat.com> Message-ID: <1184194542.2838.157.camel@localhost.localdomain> On Wed, 2007-07-11 at 15:50 -0700, Pete Rowley wrote: > Andrew Bartlett wrote: > > On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > > > >> Simo Sorce wrote: > >> > >>> On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > >>> > >>> > >>>> Getting something up to argue over :) > >>>> > >>>> http://freeipa.com/page/SchemaV1 > >>>> > >>>> > >>> Questions and remarks: > >>> - what is/why dc=com ? > >>> > >>> > >> could be dc=org or whatever that component of the realm name is. The > >> important thing is the splitting off of the most significant portion of > >> the realm name from the suffix to be part of DIT (replacing cn=default > >> which we didn't like) > >> > > > > Doesn't that break referrals to other DIT trees that may hold other > > parts of the data? > > > I don't think so, but then I don't think we are going to support such a > model. It just seems ugly and inconsistent to start that far up the domain tree. And it seems to invite someone to hard-code dc=com, then be busted when deployed to dc=au... > >> > >> OK I'll re-word it - it's discovery, since we have this partitioned off > >> into a separate space so that clients can search through only the things > >> they are interested in I thought it would be a good idea to be able to > >> discover where that place is. > >> > > > > Could this be in the rootDSE? > > > That was my first thought too, but I don't think we can modify that. We > actually have info you might put into rootDSE placed in the suffix entry. If we can't modify it, can we at least have the clients search the published suffixes (we do publish them somehow don't we?) for objectClass=ipaRealm? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From prowley at redhat.com Wed Jul 11 23:39:23 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 11 Jul 2007 16:39:23 -0700 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184194542.2838.157.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184193795.2838.153.camel@localhost.localdomain> <46955EC7.3030102@redhat.com> <1184194542.2838.157.camel@localhost.localdomain> Message-ID: <46956A2B.6000100@redhat.com> Andrew Bartlett wrote: > On Wed, 2007-07-11 at 15:50 -0700, Pete Rowley wrote: > >> Andrew Bartlett wrote: >> >>> On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: >>> >>> >>>> Simo Sorce wrote: >>>> >>>> >>>>> On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: >>>>> >>>>> >>>>> >>>>>> Getting something up to argue over :) >>>>>> >>>>>> http://freeipa.com/page/SchemaV1 >>>>>> >>>>>> >>>>>> >>>>> Questions and remarks: >>>>> - what is/why dc=com ? >>>>> >>>>> >>>>> >>>> could be dc=org or whatever that component of the realm name is. The >>>> important thing is the splitting off of the most significant portion of >>>> the realm name from the suffix to be part of DIT (replacing cn=default >>>> which we didn't like) >>>> >>>> >>> Doesn't that break referrals to other DIT trees that may hold other >>> parts of the data? >>> >>> >> I don't think so, but then I don't think we are going to support such a >> model. >> > > It just seems ugly and inconsistent to start that far up the domain > tree. /shrug - that's how they thought all trees would look originally, or at least, the one tree to rule them all :) Not married to it though, I was just looking for a way of renaming cn=default which simo wanted. > And it seems to invite someone to hard-code dc=com, then be > busted when deployed to dc=au... > > I don't see how that is any more true than with any other suffix. The dc=com can actually be any suffix, but in practice our install scripts will create the suffix and create this tree structure. If clients are likely to hard code anything it would be the basedn = the kerberos realm/dns domain name dc-ified, which would be right and we'll try to keep it that way. OTOH if anyone can come up with a nice name for the dc=realm bit (which used to be called cn=default - ick) we can drop this. > > If we can't modify it, can we at least have the clients search the > published suffixes (we do publish them somehow don't we?) yes in rootDSE in namingContexts attribute > for > objectClass=ipaRealm? > that's the idea -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From taruishi at redhat.com Thu Jul 12 02:05:48 2007 From: taruishi at redhat.com (Masato Taruishi) Date: Thu, 12 Jul 2007 11:05:48 +0900 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184183277.31248.10.camel@localhost.localdomain> References: <1184183277.31248.10.camel@localhost.localdomain> Message-ID: <1184205948.24805.8.camel@x60.taruishi.net> 2007-07-11 (?) ? 15:47 -0400 ? Karl MacMillan ????????: > I put up the start of some notes on the architecture - including a > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > What besides the toplevel diagram is needed? Other comments? What kind of authentication method the web admin console provide? NegotiateAuth and/or SPNEGO? http://en.wikipedia.org/wiki/SPNEGO http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/negotiate.html Taru > Karl > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel From abartlet at samba.org Thu Jul 12 03:02:56 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 12 Jul 2007 13:02:56 +1000 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184205948.24805.8.camel@x60.taruishi.net> References: <1184183277.31248.10.camel@localhost.localdomain> <1184205948.24805.8.camel@x60.taruishi.net> Message-ID: <1184209376.2838.188.camel@localhost.localdomain> On Thu, 2007-07-12 at 11:05 +0900, Masato Taruishi wrote: > 2007-07-11 (?) ? 15:47 -0400 ? Karl MacMillan ????????: > > I put up the start of some notes on the architecture - including a > > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > > > What besides the toplevel diagram is needed? Other comments? > > What kind of authentication method the web admin console provide? > > NegotiateAuth and/or SPNEGO? > > http://en.wikipedia.org/wiki/SPNEGO > http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/negotiate.html In practice, these are the same. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Thu Jul 12 12:22:52 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 08:22:52 -0400 Subject: [Freeipa-devel] Architecture diagram In-Reply-To: <1184205948.24805.8.camel@x60.taruishi.net> References: <1184183277.31248.10.camel@localhost.localdomain> <1184205948.24805.8.camel@x60.taruishi.net> Message-ID: <1184242972.25782.2.camel@localhost.localdomain> On Thu, 2007-07-12 at 11:05 +0900, Masato Taruishi wrote: > 2007-07-11 (?) ? 15:47 -0400 ? Karl MacMillan ????????: > > I put up the start of some notes on the architecture - including a > > diagram - at http://freeipa.com/page/IpaArchitectureV1. > > > > What besides the toplevel diagram is needed? Other comments? > > What kind of authentication method the web admin console provide? > > NegotiateAuth and/or SPNEGO? > > http://en.wikipedia.org/wiki/SPNEGO > http://meta.cesnet.cz/cms/opencms/en/docs/software/devel/negotiate.html The idea is to use SPNEGO/Kerberos with forwardable tickets. Simo. From ssorce at redhat.com Thu Jul 12 12:45:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 08:45:27 -0400 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <4695585E.9070707@redhat.com> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> Message-ID: <1184244327.25782.9.camel@localhost.localdomain> On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > Simo Sorce wrote: > > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > > > >> Getting something up to argue over :) > >> > >> http://freeipa.com/page/SchemaV1 > >> > > > > Questions and remarks: > > - what is/why dc=com ? > > > could be dc=org or whatever that component of the realm name is. The > important thing is the splitting off of the most significant portion of > the realm name from the suffix to be part of DIT (replacing cn=default > which we didn't like) Ooooh now I see the point, but I honestly don't like it :) > > - I removed uniqueidentifier: IPA for now, as it is redundant (info: IPa > > v1.0 is enough) > > > I don't think clients should have to parse the string in any fashion > other than compare in order to be sure this is an IPA server. What's wrong with this search filter: (&(objectClass=pilotObject)(info=IPA*)) ? > > - more info on objcetcalss: ipaRealm ? Why do we need it ? The > > exp-lanation on the page is not really clear to me. > > > > > OK I'll re-word it - it's discovery, since we have this partitioned off > into a separate space so that clients can search through only the things > they are interested in I thought it would be a good idea to be able to > discover where that place is. I see, it make sense for our discovery utility indeed,but this is not something we can "backport" to older clients or other OSs clients unfortunately. Also I am strating wondering if we really need to separate Users and Groups in different OUs ... yes we do cause bloody Unix has 2 different name spaces for users and groups :( Simo. From ssorce at redhat.com Thu Jul 12 12:52:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 08:52:10 -0400 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <46956A2B.6000100@redhat.com> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184193795.2838.153.camel@localhost.localdomain> <46955EC7.3030102@redhat.com> <1184194542.2838.157.camel@localhost.localdomain> <46956A2B.6000100@redhat.com> Message-ID: <1184244730.25782.17.camel@localhost.localdomain> On Wed, 2007-07-11 at 16:39 -0700, Pete Rowley wrote: > I don't see how that is any more true than with any other suffix. The > dc=com can actually be any suffix, but in practice our install scripts > will create the suffix and create this tree structure. If clients are > likely to hard code anything it would be the basedn = the kerberos > realm/dns domain name dc-ified, which would be right and we'll try to > keep it that way. I still think we don't want to go the dc=com way, we may not support it now, but maybe in future we will want to support child domains (like windows does) and replicate trees between servers. If we go the dc=com way we will not be able to do that and keep separate kerberos/system trees. > OTOH if anyone can come up with a nice name for the dc=realm bit (which > used to be called cn=default - ick) we can drop this. cn=realm ? :-) > > If we can't modify it, can we at least have the clients search the > > published suffixes (we do publish them somehow don't we?) > yes in rootDSE in namingContexts attribute > > for > > objectClass=ipaRealm? > > > that's the idea right now I use the namingContext to locate the basedn, and then I search for "info=IPA*" nn it to make sure it is an IPA server. I don't want to go further in the tree, because in future we may want to deny access to the rest of the tree to anonymous queries. if we keep all discovery (which usually mean anonymous queries) confined to the basedn it is better I think. That said we could ad an ipaRealm objectclass in future, when we will do machine joins, we will have kerberos keytabs on the machines and no anonymous queries. Simo. From abartlet at samba.org Thu Jul 12 12:54:40 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 12 Jul 2007 22:54:40 +1000 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184244327.25782.9.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184244327.25782.9.camel@localhost.localdomain> Message-ID: <1184244880.2838.197.camel@localhost.localdomain> On Thu, 2007-07-12 at 08:45 -0400, Simo Sorce wrote: > On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > > Simo Sorce wrote: > > > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > > > > > >> Getting something up to argue over :) > > >> > > >> http://freeipa.com/page/SchemaV1 > > >> > > > > > > Questions and remarks: > > > - what is/why dc=com ? > > > > > could be dc=org or whatever that component of the realm name is. The > > important thing is the splitting off of the most significant portion of > > the realm name from the suffix to be part of DIT (replacing cn=default > > which we didn't like) > > Ooooh now I see the point, but I honestly don't like it :) I'm still unclear: If my realm was abartlet.net, are things under dc=abartlet,dc=net, with that DN having an extra objectClass of ipaRealm? > > > - I removed uniqueidentifier: IPA for now, as it is redundant (info: IPa > > > v1.0 is enough) > > > > > I don't think clients should have to parse the string in any fashion > > other than compare in order to be sure this is an IPA server. > > What's wrong with this search filter: > (&(objectClass=pilotObject)(info=IPA*)) ? > > > > - more info on objcetcalss: ipaRealm ? Why do we need it ? The > > > exp-lanation on the page is not really clear to me. > > > > > > > > OK I'll re-word it - it's discovery, since we have this partitioned off > > into a separate space so that clients can search through only the things > > they are interested in I thought it would be a good idea to be able to > > discover where that place is. > > I see, it make sense for our discovery utility indeed,but this is not > something we can "backport" to older clients or other OSs clients > unfortunately. > Also I am strating wondering if we really need to separate Users and > Groups in different OUs ... yes we do cause bloody Unix has 2 different > name spaces for users and groups :( Having them in the same spot would make mapping to the AD style easier... Why can't they be under cn=group and uid=user? Or better still, as we need the names to be unique for samba (even v3), just make that a restriction? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Thu Jul 12 13:18:20 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 09:18:20 -0400 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184244880.2838.197.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184244327.25782.9.camel@localhost.localdomain> <1184244880.2838.197.camel@localhost.localdomain> Message-ID: <1184246300.25782.22.camel@localhost.localdomain> On Thu, 2007-07-12 at 22:54 +1000, Andrew Bartlett wrote: > On Thu, 2007-07-12 at 08:45 -0400, Simo Sorce wrote: > > On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > > > Simo Sorce wrote: > > > > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > > > > > > > >> Getting something up to argue over :) > > > >> > > > >> http://freeipa.com/page/SchemaV1 > > > >> > > > > > > > > Questions and remarks: > > > > - what is/why dc=com ? > > > > > > > could be dc=org or whatever that component of the realm name is. The > > > important thing is the splitting off of the most significant portion of > > > the realm name from the suffix to be part of DIT (replacing cn=default > > > which we didn't like) > > > > Ooooh now I see the point, but I honestly don't like it :) > > I'm still unclear: If my realm was abartlet.net, are things under > dc=abartlet,dc=net, with that DN having an extra objectClass of > ipaRealm? Pete proposal was: dc=net (objectclass=pilotObject / info=IPA v1.0) |- cn=system | |-cn=kerberos | \-cn=ipa |-dc=abartlet (objectclass=ipaRealm) |-ou=people |-ou=groups I say now: dc=abartlet,dc=net (objectclass=pilotObject / info=IPA v1.0) |- cn=system | |-cn=kerberos | \-cn=ipa |- cn=realm |-ou=people |-ou=groups Make sense? > > I see, it make sense for our discovery utility indeed,but this is > not > > something we can "backport" to older clients or other OSs clients > > unfortunately. > > Also I am strating wondering if we really need to separate Users and > > Groups in different OUs ... yes we do cause bloody Unix has 2 > different > > name spaces for users and groups :( > > Having them in the same spot would make mapping to the AD style > easier... > > Why can't they be under cn=group and uid=user? Or better still, as we > need the names to be unique for samba (even v3), just make that a > restriction? I know, I wa even thinking of forcibly merging personal groups into users and have a monotonic merged uid/gid counter so that we basically mege the user and group spaces. but I need a lot of time to explain why this make sense in general and specifically for interoperate with Windows. Is this interesting for v1? Or should we delay discussions for post v1? Simo. From abartlet at samba.org Thu Jul 12 13:24:46 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 12 Jul 2007 23:24:46 +1000 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184246300.25782.22.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184244327.25782.9.camel@localhost.localdomain> <1184244880.2838.197.camel@localhost.localdomain> <1184246300.25782.22.camel@localhost.localdomain> Message-ID: <1184246686.2838.205.camel@localhost.localdomain> On Thu, 2007-07-12 at 09:18 -0400, Simo Sorce wrote: > On Thu, 2007-07-12 at 22:54 +1000, Andrew Bartlett wrote: > > On Thu, 2007-07-12 at 08:45 -0400, Simo Sorce wrote: > > > On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > > > > Simo Sorce wrote: > > > > > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > > > > > > > > > >> Getting something up to argue over :) > > > > >> > > > > >> http://freeipa.com/page/SchemaV1 > > > > >> > > > > > > > > > > Questions and remarks: > > > > > - what is/why dc=com ? > > > > > > > > > could be dc=org or whatever that component of the realm name is. The > > > > important thing is the splitting off of the most significant portion of > > > > the realm name from the suffix to be part of DIT (replacing cn=default > > > > which we didn't like) > > > > > > Ooooh now I see the point, but I honestly don't like it :) > > > > I'm still unclear: If my realm was abartlet.net, are things under > > dc=abartlet,dc=net, with that DN having an extra objectClass of > > ipaRealm? > > Pete proposal was: > dc=net (objectclass=pilotObject / info=IPA v1.0) > |- cn=system > | |-cn=kerberos > | \-cn=ipa > |-dc=abartlet (objectclass=ipaRealm) > |-ou=people > |-ou=groups > > I say now: > > dc=abartlet,dc=net (objectclass=pilotObject / info=IPA v1.0) > |- cn=system > | |-cn=kerberos > | \-cn=ipa > |- cn=realm > |-ou=people > |-ou=groups > > Make sense? I would love to get rid of the cn=realm level, if possible. (keep cn=system as proposed, or possibly renamed to avoid a conflict with the AD use of cn=system). > > > I see, it make sense for our discovery utility indeed,but this is > > not > > > something we can "backport" to older clients or other OSs clients > > > unfortunately. > > > Also I am strating wondering if we really need to separate Users and > > > Groups in different OUs ... yes we do cause bloody Unix has 2 > > different > > > name spaces for users and groups :( > > > > Having them in the same spot would make mapping to the AD style > > easier... > > > > Why can't they be under cn=group and uid=user? Or better still, as we > > need the names to be unique for samba (even v3), just make that a > > restriction? > > I know, I wa even thinking of forcibly merging personal groups into > users and have a monotonic merged uid/gid counter so that we basically > mege the user and group spaces. but I need a lot of time to explain why > this make sense in general and specifically for interoperate with > Windows. It depends how seriously we want to take that, I suppose. > Is this interesting for v1? Or should we delay discussions for post v1? Do we break the ability to go beyond v1 if we don't address it? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Jul 12 14:23:48 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jul 2007 10:23:48 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184102969.9377.0.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> Message-ID: <46963974.2040308@redhat.com> Simo Sorce wrote: > On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: >> So I was thinking about the XML-RPC portion of this. >> >> One thing we'll be doing is setting and resetting user passwords. So we >> should use SSL to protect them, if for no other reaosn. >> >> So: >> >> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings >> I couldn't find them. OLPC may do this work for us >> (http://dev.laptop.org/ticket/855) >> >> 2. How will we manage trust between the gui and command-line clients and >> XML-RPC server? > > IF we are going to use kerberos, can't we just use GSSAPI to encrypt > traffic? I can't find any information on how to do this (GSSAPI over HTTP). Do you have any pointers? thanks rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Thu Jul 12 14:29:05 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 12 Jul 2007 10:29:05 -0400 Subject: [Freeipa-devel] [Fwd: Integrating a RHEL5 system within a Microsoft Active Directory infrastructure] Message-ID: <1184250545.4603.1.camel@chickadee.boston.redhat.com> Forwarding to this list as I think the expertise is here and you all might not hang out on tech-list. Just be aware of cross post issues. -- John Dennis -------------- next part -------------- An embedded message was scrubbed... From: Olivier Fourdan Subject: Integrating a RHEL5 system within a Microsoft Active Directory infrastructure Date: Thu, 12 Jul 2007 14:46:28 +0100 Size: 5036 URL: From ssorce at redhat.com Thu Jul 12 14:29:13 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 10:29:13 -0400 Subject: [Freeipa-devel] First cut of schema doc In-Reply-To: <1184246686.2838.205.camel@localhost.localdomain> References: <4695513E.8060001@redhat.com> <1184191664.9377.25.camel@localhost.localdomain> <4695585E.9070707@redhat.com> <1184244327.25782.9.camel@localhost.localdomain> <1184244880.2838.197.camel@localhost.localdomain> <1184246300.25782.22.camel@localhost.localdomain> <1184246686.2838.205.camel@localhost.localdomain> Message-ID: <1184250553.25782.31.camel@localhost.localdomain> On Thu, 2007-07-12 at 23:24 +1000, Andrew Bartlett wrote: > On Thu, 2007-07-12 at 09:18 -0400, Simo Sorce wrote: > > On Thu, 2007-07-12 at 22:54 +1000, Andrew Bartlett wrote: > > > On Thu, 2007-07-12 at 08:45 -0400, Simo Sorce wrote: > > > > On Wed, 2007-07-11 at 15:23 -0700, Pete Rowley wrote: > > > > > Simo Sorce wrote: > > > > > > On Wed, 2007-07-11 at 14:53 -0700, Pete Rowley wrote: > > > > > > > > > > > >> Getting something up to argue over :) > > > > > >> > > > > > >> http://freeipa.com/page/SchemaV1 > > > > > >> > > > > > > > > > > > > Questions and remarks: > > > > > > - what is/why dc=com ? > > > > > > > > > > > could be dc=org or whatever that component of the realm name is. The > > > > > important thing is the splitting off of the most significant portion of > > > > > the realm name from the suffix to be part of DIT (replacing cn=default > > > > > which we didn't like) > > > > > > > > Ooooh now I see the point, but I honestly don't like it :) > > > > > > I'm still unclear: If my realm was abartlet.net, are things under > > > dc=abartlet,dc=net, with that DN having an extra objectClass of > > > ipaRealm? > > > > Pete proposal was: > > dc=net (objectclass=pilotObject / info=IPA v1.0) > > |- cn=system > > | |-cn=kerberos > > | \-cn=ipa > > |-dc=abartlet (objectclass=ipaRealm) > > |-ou=people > > |-ou=groups > > > > I say now: > > > > dc=abartlet,dc=net (objectclass=pilotObject / info=IPA v1.0) > > |- cn=system > > | |-cn=kerberos > > | \-cn=ipa > > |- cn=realm > > |-ou=people > > |-ou=groups > > > > Make sense? > > I would love to get rid of the cn=realm level, if possible. (keep > cn=system as proposed, or possibly renamed to avoid a conflict with the > AD use of cn=system). I proposed the use of a middle layer to avoid lazy people to make DS search the complete tree every time when looking for users or groups as it would happen with people using "dc=abartlet,dc=net" as the basedn for their searches. I guess indexes will not make this a big deal, but yet I feel that adding a component like this will be helpful later to make sure searches can't find wrong entries. For example if we decide at some point to support multiple realms we will be able to simply add other nodes under the basedn without having clients see all user accounts from all realms. I proposed the name cn=system, pete proposed cn=global services, what do you propose? :-) However I am really keen into exploring if using views or some slapi plugin can help us keep a "view" that is more easy to handle for samba4. > > I know, I wa even thinking of forcibly merging personal groups into > > users and have a monotonic merged uid/gid counter so that we basically > > mege the user and group spaces. but I need a lot of time to explain why > > this make sense in general and specifically for interoperate with > > Windows. > > It depends how seriously we want to take that, I suppose. That is a big problem. And I know there is a lot of resistance in this area. > > Is this interesting for v1? Or should we delay discussions for post v1? > > Do we break the ability to go beyond v1 if we don't address it? I think we will have to change _many_ things for v2 or v3, if we are going to constrain ourselves to the v1 way of doing things, I think we will not go too far. I really prefer to be forced to create a complex migration program than to feel constrained by v1 legacy. Simo. From ssorce at redhat.com Thu Jul 12 14:32:58 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 10:32:58 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <46963974.2040308@redhat.com> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> Message-ID: <1184250778.25782.33.camel@localhost.localdomain> On Thu, 2007-07-12 at 10:23 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: > >> So I was thinking about the XML-RPC portion of this. > >> > >> One thing we'll be doing is setting and resetting user passwords. So we > >> should use SSL to protect them, if for no other reaosn. > >> > >> So: > >> > >> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings > >> I couldn't find them. OLPC may do this work for us > >> (http://dev.laptop.org/ticket/855) > >> > >> 2. How will we manage trust between the gui and command-line clients and > >> XML-RPC server? > > > > IF we are going to use kerberos, can't we just use GSSAPI to encrypt > > traffic? > > I can't find any information on how to do this (GSSAPI over HTTP). Do > you have any pointers? IIRC RFC4559. Simo. From rcritten at redhat.com Thu Jul 12 14:44:02 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jul 2007 10:44:02 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184250778.25782.33.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> Message-ID: <46963E32.5080608@redhat.com> Simo Sorce wrote: > On Thu, 2007-07-12 at 10:23 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: >>>> So I was thinking about the XML-RPC portion of this. >>>> >>>> One thing we'll be doing is setting and resetting user passwords. So we >>>> should use SSL to protect them, if for no other reaosn. >>>> >>>> So: >>>> >>>> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings >>>> I couldn't find them. OLPC may do this work for us >>>> (http://dev.laptop.org/ticket/855) >>>> >>>> 2. How will we manage trust between the gui and command-line clients and >>>> XML-RPC server? >>> IF we are going to use kerberos, can't we just use GSSAPI to encrypt >>> traffic? >> I can't find any information on how to do this (GSSAPI over HTTP). Do >> you have any pointers? > > IIRC RFC4559. > > Simo. > Thanks This RFC defines authentication (the Negotiate mechanism). Further in the document is this: 6. Security Considerations The SPNEGO HTTP authentication facility is only used to provide authentication of a user to a server. It provides no facilities for protecting the HTTP headers or data including the Authorization and WWW-Authenticate headers that are used to implement this mechanism. Alternate mechanisms such as TLS can be used to provide confidentiality. I did find an expired draft (from 2001) that added SASL support to HTTP/1.1 via the Upgrade header but then any clients that wanted to use this would need to add this feature as well. I wonder if there is a way to have our clients automatically download the CA certificate after authenticating. It won't impede others from using our XML-RPC server, they will just need to manually install the CA. That or we install the CA on client machines as part of our client configuration mechanism. The on-the-fly method might look something like: Make SSL connection If fail due to lack-of-trust: Authenticate to HTTP listener using Kerberos If auth-fails: print nice error message else: download CA cert Restart request over HTTPS Continue The downside is that this adds a fair bit of complexity and requires 2 listeners. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Thu Jul 12 14:55:27 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 10:55:27 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <46963E32.5080608@redhat.com> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> Message-ID: <1184252127.25782.42.camel@localhost.localdomain> On Thu, 2007-07-12 at 10:44 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Thu, 2007-07-12 at 10:23 -0400, Rob Crittenden wrote: > >> Simo Sorce wrote: > >>> On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: > >>>> So I was thinking about the XML-RPC portion of this. > >>>> > >>>> One thing we'll be doing is setting and resetting user passwords. So we > >>>> should use SSL to protect them, if for no other reaosn. > >>>> > >>>> So: > >>>> > >>>> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings > >>>> I couldn't find them. OLPC may do this work for us > >>>> (http://dev.laptop.org/ticket/855) > >>>> > >>>> 2. How will we manage trust between the gui and command-line clients and > >>>> XML-RPC server? > >>> IF we are going to use kerberos, can't we just use GSSAPI to encrypt > >>> traffic? > >> I can't find any information on how to do this (GSSAPI over HTTP). Do > >> you have any pointers? > > > > IIRC RFC4559. > > > > Simo. > > > > Thanks > > This RFC defines authentication (the Negotiate mechanism). > > Further in the document is this: > > 6. Security Considerations > > The SPNEGO HTTP authentication facility is only used to provide > authentication of a user to a server. It provides no facilities for > protecting the HTTP headers or data including the Authorization and > WWW-Authenticate headers that are used to implement this mechanism. > > Alternate mechanisms such as TLS can be used to provide > confidentiality. > > I did find an expired draft (from 2001) that added SASL support to > HTTP/1.1 via the Upgrade header but then any clients that wanted to use > this would need to add this feature as well. Yeah, I remembered there was something but didn't know how far it got, not much it seem. That said we could still do encapsulation ourselves, but that would probably require modifying too much code and won't be xml-rpc compliant, too bad, maybe we can think of something for v2/v3. > I wonder if there is a way to have our clients automatically download > the CA certificate after authenticating. It won't impede others from > using our XML-RPC server, they will just need to manually install the > CA. That or we install the CA on client machines as part of our client > configuration mechanism. > > The on-the-fly method might look something like: > > Make SSL connection > If fail due to lack-of-trust: > Authenticate to HTTP listener using Kerberos > If auth-fails: > print nice error message > else: > download CA cert > Restart request over HTTPS > Continue > > The downside is that this adds a fair bit of complexity and requires 2 > listeners. My take is this: Normal case: During client configuration use the admin credentials to connect to the LDAP server and download a CA certificate from there (LDAP may also contain the CRL while we are at that), and put it on the machine. I guess we can make it available to all browsers somehow ? Other cases: let people know where to download the certificate which will be published in a standard location on an unprotected page. Also let them just use self-signed certificates (take the signature at the first connection and save it somewhere and trust it). Simo. From rcritten at redhat.com Thu Jul 12 15:34:44 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jul 2007 11:34:44 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184252127.25782.42.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> Message-ID: <46964A14.40701@redhat.com> Simo Sorce wrote: > On Thu, 2007-07-12 at 10:44 -0400, Rob Crittenden wrote: >> Simo Sorce wrote: >>> On Thu, 2007-07-12 at 10:23 -0400, Rob Crittenden wrote: >>>> Simo Sorce wrote: >>>>> On Tue, 2007-07-10 at 17:11 -0400, Rob Crittenden wrote: >>>>>> So I was thinking about the XML-RPC portion of this. >>>>>> >>>>>> One thing we'll be doing is setting and resetting user passwords. So we >>>>>> should use SSL to protect them, if for no other reaosn. >>>>>> >>>>>> So: >>>>>> >>>>>> 1. I assume we'll have to use OpenSSL. If there are Python NSS bindings >>>>>> I couldn't find them. OLPC may do this work for us >>>>>> (http://dev.laptop.org/ticket/855) >>>>>> >>>>>> 2. How will we manage trust between the gui and command-line clients and >>>>>> XML-RPC server? >>>>> IF we are going to use kerberos, can't we just use GSSAPI to encrypt >>>>> traffic? >>>> I can't find any information on how to do this (GSSAPI over HTTP). Do >>>> you have any pointers? >>> IIRC RFC4559. >>> >>> Simo. >>> >> Thanks >> >> This RFC defines authentication (the Negotiate mechanism). >> >> Further in the document is this: >> >> 6. Security Considerations >> >> The SPNEGO HTTP authentication facility is only used to provide >> authentication of a user to a server. It provides no facilities for >> protecting the HTTP headers or data including the Authorization and >> WWW-Authenticate headers that are used to implement this mechanism. >> >> Alternate mechanisms such as TLS can be used to provide >> confidentiality. >> >> I did find an expired draft (from 2001) that added SASL support to >> HTTP/1.1 via the Upgrade header but then any clients that wanted to use >> this would need to add this feature as well. > > Yeah, I remembered there was something but didn't know how far it got, > not much it seem. That said we could still do encapsulation ourselves, > but that would probably require modifying too much code and won't be > xml-rpc compliant, too bad, maybe we can think of something for v2/v3. > >> I wonder if there is a way to have our clients automatically download >> the CA certificate after authenticating. It won't impede others from >> using our XML-RPC server, they will just need to manually install the >> CA. That or we install the CA on client machines as part of our client >> configuration mechanism. >> >> The on-the-fly method might look something like: >> >> Make SSL connection >> If fail due to lack-of-trust: >> Authenticate to HTTP listener using Kerberos >> If auth-fails: >> print nice error message >> else: >> download CA cert >> Restart request over HTTPS >> Continue >> >> The downside is that this adds a fair bit of complexity and requires 2 >> listeners. > > My take is this: > Normal case: During client configuration use the admin credentials to > connect to the LDAP server and download a CA certificate from there > (LDAP may also contain the CRL while we are at that), and put it on the > machine. I guess we can make it available to all browsers somehow ? > > Other cases: let people know where to download the certificate which > will be published in a standard location on an unprotected page. Also > let them just use self-signed certificates (take the signature at the > first connection and save it somewhere and trust it). Yes, providing a pointer would probably be helpful. The trick would be in getting the server to tell the location. I think we need to revisit the resistance to Apache here. It already provides kerberos authentication with ticket forwarding. It seems like reinventing the wheel doing it in Python instead. koji/brew use Apache as the front-end and it seems to work ok. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kwirth at redhat.com Thu Jul 12 16:18:13 2007 From: kwirth at redhat.com (Karl Wirth) Date: Thu, 12 Jul 2007 12:18:13 -0400 Subject: [Freeipa-devel] Posted requirements docs for IPA v1 and v2 In-Reply-To: <1184252127.25782.42.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> Message-ID: <46965445.9080707@redhat.com> I posted requirements docs for IPA v1 and v2 on www.freeipa.org. You can find them under roadmap and also under documentation. IPA v1 requirements are fairly well baked and IPA v2 requirements are just a very rough draft. Please give suggestions for both. Regards, Karl From ssorce at redhat.com Thu Jul 12 18:31:28 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 14:31:28 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <46964A14.40701@redhat.com> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> <46964A14.40701@redhat.com> Message-ID: <1184265088.25782.45.camel@localhost.localdomain> On Thu, 2007-07-12 at 11:34 -0400, Rob Crittenden wrote: > I think we need to revisit the resistance to Apache here. It already > provides kerberos authentication with ticket forwarding. It seems > like > reinventing the wheel doing it in Python instead. koji/brew use > Apache > as the front-end and it seems to work ok. If you can come up with a simple way to drop a configuration file in the pache dir that does all we need (simply doing an service httpd restart) then I think using apache may make sense. I don't think people will use the same box to store identities and to serve casual HTTP content anyway :) Simo. From kmacmill at redhat.com Thu Jul 12 18:34:14 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 12 Jul 2007 14:34:14 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184265088.25782.45.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> <46964A14.40701@redhat.com> <1184265088.25782.45.camel@localhost.localdomain> Message-ID: <1184265254.7779.8.camel@localhost.localdomain> On Thu, 2007-07-12 at 14:31 -0400, Simo Sorce wrote: > On Thu, 2007-07-12 at 11:34 -0400, Rob Crittenden wrote: > > > I think we need to revisit the resistance to Apache here. It already > > provides kerberos authentication with ticket forwarding. It seems > > like > > reinventing the wheel doing it in Python instead. koji/brew use > > Apache > > as the front-end and it seems to work ok. > > If you can come up with a simple way to drop a configuration file in the > pache dir that does all we need (simply doing an service httpd restart) > then I think using apache may make sense. > I don't think people will use the same box to store identities and to > serve casual HTTP content anyway :) > That's fine with me - and we already require it for the DS admin server. And since we were planning on taking over port 80 with some server I don't think people could use the box for web serving anyway. What about the xml-rpc layer though? Karl From ssorce at redhat.com Thu Jul 12 18:35:54 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 14:35:54 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184265254.7779.8.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> <46964A14.40701@redhat.com> <1184265088.25782.45.camel@localhost.localdomain> <1184265254.7779.8.camel@localhost.localdomain> Message-ID: <1184265354.25782.47.camel@localhost.localdomain> On Thu, 2007-07-12 at 14:34 -0400, Karl MacMillan wrote: > On Thu, 2007-07-12 at 14:31 -0400, Simo Sorce wrote: > > On Thu, 2007-07-12 at 11:34 -0400, Rob Crittenden wrote: > > > > > I think we need to revisit the resistance to Apache here. It already > > > provides kerberos authentication with ticket forwarding. It seems > > > like > > > reinventing the wheel doing it in Python instead. koji/brew use > > > Apache > > > as the front-end and it seems to work ok. > > > > If you can come up with a simple way to drop a configuration file in the > > pache dir that does all we need (simply doing an service httpd restart) > > then I think using apache may make sense. > > I don't think people will use the same box to store identities and to > > serve casual HTTP content anyway :) > > > > That's fine with me - and we already require it for the DS admin server. > And since we were planning on taking over port 80 with some server I > don't think people could use the box for web serving anyway. You mean 443 here, right? :-) > What about the xml-rpc layer though? What about it ? Simo. From kmacmill at redhat.com Thu Jul 12 18:45:51 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 12 Jul 2007 14:45:51 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184265354.25782.47.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> <46964A14.40701@redhat.com> <1184265088.25782.45.camel@localhost.localdomain> <1184265254.7779.8.camel@localhost.localdomain> <1184265354.25782.47.camel@localhost.localdomain> Message-ID: <1184265951.7779.10.camel@localhost.localdomain> On Thu, 2007-07-12 at 14:35 -0400, Simo Sorce wrote: > On Thu, 2007-07-12 at 14:34 -0400, Karl MacMillan wrote: > > On Thu, 2007-07-12 at 14:31 -0400, Simo Sorce wrote: > > > On Thu, 2007-07-12 at 11:34 -0400, Rob Crittenden wrote: > > > > > > > I think we need to revisit the resistance to Apache here. It already > > > > provides kerberos authentication with ticket forwarding. It seems > > > > like > > > > reinventing the wheel doing it in Python instead. koji/brew use > > > > Apache > > > > as the front-end and it seems to work ok. > > > > > > If you can come up with a simple way to drop a configuration file in the > > > pache dir that does all we need (simply doing an service httpd restart) > > > then I think using apache may make sense. > > > I don't think people will use the same box to store identities and to > > > serve casual HTTP content anyway :) > > > > > > > That's fine with me - and we already require it for the DS admin server. > > And since we were planning on taking over port 80 with some server I > > don't think people could use the box for web serving anyway. > > You mean 443 here, right? :-) > Oops. > > What about the xml-rpc layer though? > > What about it ? > Will it also go through apache? Karl > Simo. > From ssorce at redhat.com Thu Jul 12 18:50:10 2007 From: ssorce at redhat.com (Simo Sorce) Date: Thu, 12 Jul 2007 14:50:10 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184265951.7779.10.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> <46964A14.40701@redhat.com> <1184265088.25782.45.camel@localhost.localdomain> <1184265254.7779.8.camel@localhost.localdomain> <1184265354.25782.47.camel@localhost.localdomain> <1184265951.7779.10.camel@localhost.localdomain> Message-ID: <1184266210.25782.49.camel@localhost.localdomain> On Thu, 2007-07-12 at 14:45 -0400, Karl MacMillan wrote: > > > What about the xml-rpc layer though? > > > > What about it ? > > > > Will it also go through apache? Why not ? Simo. From rcritten at redhat.com Thu Jul 12 19:19:14 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Jul 2007 15:19:14 -0400 Subject: [Freeipa-devel] SSL In-Reply-To: <1184265951.7779.10.camel@localhost.localdomain> References: <4693F5FA.1060803@redhat.com> <1184102969.9377.0.camel@localhost.localdomain> <46963974.2040308@redhat.com> <1184250778.25782.33.camel@localhost.localdomain> <46963E32.5080608@redhat.com> <1184252127.25782.42.camel@localhost.localdomain> <46964A14.40701@redhat.com> <1184265088.25782.45.camel@localhost.localdomain> <1184265254.7779.8.camel@localhost.localdomain> <1184265354.25782.47.camel@localhost.localdomain> <1184265951.7779.10.camel@localhost.localdomain> Message-ID: <46967EB2.2020500@redhat.com> Karl MacMillan wrote: > On Thu, 2007-07-12 at 14:35 -0400, Simo Sorce wrote: >> On Thu, 2007-07-12 at 14:34 -0400, Karl MacMillan wrote: >>> On Thu, 2007-07-12 at 14:31 -0400, Simo Sorce wrote: >>>> On Thu, 2007-07-12 at 11:34 -0400, Rob Crittenden wrote: >>>> >>>>> I think we need to revisit the resistance to Apache here. It already >>>>> provides kerberos authentication with ticket forwarding. It seems >>>>> like >>>>> reinventing the wheel doing it in Python instead. koji/brew use >>>>> Apache >>>>> as the front-end and it seems to work ok. >>>> If you can come up with a simple way to drop a configuration file in the >>>> pache dir that does all we need (simply doing an service httpd restart) >>>> then I think using apache may make sense. >>>> I don't think people will use the same box to store identities and to >>>> serve casual HTTP content anyway :) >>>> >>> That's fine with me - and we already require it for the DS admin server. >>> And since we were planning on taking over port 80 with some server I >>> don't think people could use the box for web serving anyway. >> You mean 443 here, right? :-) >> > > Oops. > >>> What about the xml-rpc layer though? >> What about it ? >> > > Will it also go through apache? > This is the layer I want to put behind Apache so I can inherit the kerbeors auth capability. This is what koji/brew does and it seems to work ok for them. I just need to see if I have access to the forwardable ticket via mod_python. I think it works but I want to see it. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 13 12:42:46 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jul 2007 08:42:46 -0400 Subject: [Freeipa-devel] installer problem Message-ID: <46977346.5010907@redhat.com> Some problems with the install. # /usr/sbin/ipa-server-install -r FREEIPA.ORG -a ipa -p freeipa -m ipafree Traceback (most recent call last): File "/usr/sbin/ipa-server-install", line 70, in main() File "/usr/sbin/ipa-server-install", line 61, in main ds.create_instance(options.ds_user, options.realm_name, options.host_name, options.password) File "/usr/lib/python2.5/site-packages/ipa/dsinstance.py", line 103, in create_instance self.__create_ds_user() File "/usr/lib/python2.5/site-packages/ipa/dsinstance.py", line 135, in __create_ds_user pwd.getpwnam(self.ds_user) TypeError: getpwnam() argument 1 must be string, not None Added: -u fdsuser and the install continued until it seems to have hung. I have 3 processes related to this: root 3147 3027 0 21:43 pts/2 00:00:00 /usr/bin/python -E /usr/sbin/ipa-server-install -r FREEIPA.ORG -a ipa.greyoak.com -p freeipa -m freeipa -u fdsuser fdsuser 3329 1 0 21:43 ? 00:00:00 /usr/sbin/ns-slapd -D /etc/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509 -i /var/run/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509.pid -w /var/run/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509.startpid root 3399 3147 0 21:43 pts/2 00:00:00 /usr/kerberos/sbin/kdb5_ldap_util -D uid=kdc,cn=kerberos,dc=freeipa,dc=org -w FPRYXRFYUKBV create -s -r FREEIPA.ORG -subtrees dc=freeipa,dc=org -sscope sub An strace shows krb5_ldap_util blocking on a read. Do we have an uninstall to back things out or is this not needed? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 13 13:16:44 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jul 2007 09:16:44 -0400 Subject: [Freeipa-devel] installer problem In-Reply-To: <46977346.5010907@redhat.com> References: <46977346.5010907@redhat.com> Message-ID: <46977B3C.9010800@redhat.com> Rob Crittenden wrote: > Some problems with the install. > > # /usr/sbin/ipa-server-install -r FREEIPA.ORG -a ipa -p freeipa -m ipafree > Traceback (most recent call last): > File "/usr/sbin/ipa-server-install", line 70, in > main() > File "/usr/sbin/ipa-server-install", line 61, in main > ds.create_instance(options.ds_user, options.realm_name, > options.host_name, options.password) > File "/usr/lib/python2.5/site-packages/ipa/dsinstance.py", line 103, > in create_instance > self.__create_ds_user() > File "/usr/lib/python2.5/site-packages/ipa/dsinstance.py", line 135, > in __create_ds_user > pwd.getpwnam(self.ds_user) > TypeError: getpwnam() argument 1 must be string, not None > > Added: -u fdsuser and the install continued until it seems to have hung. > > I have 3 processes related to this: > > root 3147 3027 0 21:43 pts/2 00:00:00 /usr/bin/python -E > /usr/sbin/ipa-server-install -r FREEIPA.ORG -a ipa.greyoak.com -p > freeipa -m freeipa -u fdsuser > fdsuser 3329 1 0 21:43 ? 00:00:00 /usr/sbin/ns-slapd -D > /etc/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509 -i > /var/run/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509.pid -w > /var/run/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509.startpid > root 3399 3147 0 21:43 pts/2 00:00:00 > /usr/kerberos/sbin/kdb5_ldap_util -D > uid=kdc,cn=kerberos,dc=freeipa,dc=org -w FPRYXRFYUKBV create -s -r > FREEIPA.ORG -subtrees dc=freeipa,dc=org -sscope sub > > An strace shows krb5_ldap_util blocking on a read. > > Do we have an uninstall to back things out or is this not needed? > Got a little further. kdb5_ldap_util is blocking waiting for a password ala: Initializing database for realm 'FREEIPA.ORG' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: I entered the passwords but the KDC failed to start and logged the error: krb5kdc: Unable to access Kerberos database - while initializing database for realm FREEIPA.ORG Not sure if this is a password issue or something else. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 13 13:22:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jul 2007 09:22:49 -0400 Subject: [Freeipa-devel] installer problem In-Reply-To: <46977B3C.9010800@redhat.com> References: <46977346.5010907@redhat.com> <46977B3C.9010800@redhat.com> Message-ID: <46977CA9.1040505@redhat.com> Rob Crittenden wrote: > Rob Crittenden wrote: >> Some problems with the install. >> >> # /usr/sbin/ipa-server-install -r FREEIPA.ORG -a ipa -p freeipa -m >> ipafree >> Traceback (most recent call last): >> File "/usr/sbin/ipa-server-install", line 70, in >> main() >> File "/usr/sbin/ipa-server-install", line 61, in main >> ds.create_instance(options.ds_user, options.realm_name, >> options.host_name, options.password) >> File "/usr/lib/python2.5/site-packages/ipa/dsinstance.py", line 103, >> in create_instance >> self.__create_ds_user() >> File "/usr/lib/python2.5/site-packages/ipa/dsinstance.py", line 135, >> in __create_ds_user >> pwd.getpwnam(self.ds_user) >> TypeError: getpwnam() argument 1 must be string, not None >> >> Added: -u fdsuser and the install continued until it seems to have hung. >> >> I have 3 processes related to this: >> >> root 3147 3027 0 21:43 pts/2 00:00:00 /usr/bin/python -E >> /usr/sbin/ipa-server-install -r FREEIPA.ORG -a ipa.greyoak.com -p >> freeipa -m freeipa -u fdsuser >> fdsuser 3329 1 0 21:43 ? 00:00:00 /usr/sbin/ns-slapd -D >> /etc/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509 -i >> /var/run/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509.pid -w >> /var/run/fedora-ds/slapd-6a7ff2dc-30e2-11dc-a730-000c297b5509.startpid >> root 3399 3147 0 21:43 pts/2 00:00:00 >> /usr/kerberos/sbin/kdb5_ldap_util -D >> uid=kdc,cn=kerberos,dc=freeipa,dc=org -w FPRYXRFYUKBV create -s -r >> FREEIPA.ORG -subtrees dc=freeipa,dc=org -sscope sub >> >> An strace shows krb5_ldap_util blocking on a read. >> >> Do we have an uninstall to back things out or is this not needed? >> > > Got a little further. kdb5_ldap_util is blocking waiting for a password > ala: > > Initializing database for realm 'FREEIPA.ORG' > You will be prompted for the database Master Password. > It is important that you NOT FORGET this password. > Enter KDC database master key: > Re-enter KDC database master key to verify: > > I entered the passwords but the KDC failed to start and logged the error: > > krb5kdc: Unable to access Kerberos database - while initializing > database for realm FREEIPA.ORG > > Not sure if this is a password issue or something else. > > rob > And I'm replying to myself for the last time. I think the problem was that /var/kerberos/krb5kdc/ldappwd had 3 entries in it from previous failed attempts. I removed that file and the install finally succeeded. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 13 20:19:51 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jul 2007 16:19:51 -0400 Subject: [Freeipa-devel] kerberos ticket forwarding with mod_auth_kerb Message-ID: <4697DE67.5040501@redhat.com> Well I'm having no luck at all getting ticket forwarding working. I've got basic kerberos SSO working fine. I get a forwardable ticket with: kinit -f rcrit at GREYOAK.COM klist Ticket cache: FILE:/tmp/krb5cc_10996 Default principal: rcrit at GREYOAK.COM Valid starting Expires Service principal 07/13/07 15:58:36 07/14/07 15:56:44 krbtgt/GREYOAK.COM at GREYOAK.COM Flags: FIA 07/13/07 15:58:37 07/14/07 15:56:44 HTTP/ipa.greyoak.com at GREYOAK.COM Flags: FAT Ticket cache: FILE:/tmp/krb5cc_10996 krb5.conf has forwardable=yes on the client and the kdc server. I have mod_auth_kerb configured to save them: AuthType Kerberos AuthName "Kerberos Login" KrbMethodNegotiate on KrbMethodK5Passwd off KrbServiceName HTTP KrbAuthRealms GREYOAK.COM Krb5KeyTab /etc/httpd/conf/ipa.keytab KrbSaveCredentials on Require valid-user ErrorDocument 401 /errors/unauthorized.html In my browser (Firefox 2.0.0.4) I have network.negotiate-auth.delegation-uris and network.negotiate-auth.trusted-uris set and the Firefox log seems to indicate that it is doing the right thing: -1208289600[937eeb8]: using REQ_DELEGATE -1208289600[937eeb8]: service = ipa.greyoak.com -1208289600[937eeb8]: using negotiate-gss -1208289600[937eeb8]: entering nsAuthGSSAPI::nsAuthGSSAPI() -1208289600[937eeb8]: entering nsAuthGSSAPI::Init() -1208289600[937eeb8]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] -1208289600[937eeb8]: entering nsAuthGSSAPI::GetNextToken() -1208289600[937eeb8]: leaving nsAuthGSSAPI::GetNextToken [rv=0] -1208289600[937eeb8]: Sending a token of length 1150 Assuming that REQ_DELEGATE means what I think it does. Apache is logging: [Fri Jul 13 16:15:21 2007] [debug] src/mod_auth_kerb.c(1405): [client 192.168.0.1] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Fri Jul 13 16:15:22 2007] [debug] src/mod_auth_kerb.c(1405): [client 192.168.0.1] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos [Fri Jul 13 16:15:22 2007] [debug] src/mod_auth_kerb.c(1148): [client 192.168.0.1] Acquiring creds for HTTP at ipa.greyoak.com [Fri Jul 13 16:15:22 2007] [debug] src/mod_auth_kerb.c(1240): [client 192.168.0.1] Verifying client data using KRB5 GSS-API [Fri Jul 13 16:15:22 2007] [debug] src/mod_auth_kerb.c(1256): [client 192.168.0.1] Verification returned code 0 [Fri Jul 13 16:15:22 2007] [debug] src/mod_auth_kerb.c(1274): [client 192.168.0.1] GSS-API token of length 22 bytes will be sent back [Fri Jul 13 16:15:22 2007] [debug] src/mod_auth_kerb.c(1321): [client 192.168.0.1] set cached name rcrit at GREYOAK.COM for connection The call to gss_accept_sec_context() is setting the delegated credentials to GSS_C_NO_CREDENTIAL. So I'm pretty much stumped. This is on Fedora 7 with Apache 2.2.4 and mod_auth_kerb 5.3-3 rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Fri Jul 13 20:35:17 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Jul 2007 16:35:17 -0400 Subject: [Freeipa-devel] kerberos ticket forwarding with mod_auth_kerb In-Reply-To: <4697DE67.5040501@redhat.com> References: <4697DE67.5040501@redhat.com> Message-ID: <1184358917.16008.14.camel@localhost.localdomain> On Fri, 2007-07-13 at 16:19 -0400, Rob Crittenden wrote: > This is on Fedora 7 with Apache 2.2.4 and mod_auth_kerb 5.3-3 Is the support for saving credentials compiled in ? Simo. From ssorce at redhat.com Fri Jul 13 20:37:59 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Jul 2007 16:37:59 -0400 Subject: [Freeipa-devel] kerberos ticket forwarding with mod_auth_kerb In-Reply-To: <4697DE67.5040501@redhat.com> References: <4697DE67.5040501@redhat.com> Message-ID: <1184359079.16008.17.camel@localhost.localdomain> On Fri, 2007-07-13 at 16:19 -0400, Rob Crittenden wrote: > > I have mod_auth_kerb configured to save them: > > > AuthType Kerberos > AuthName "Kerberos Login" > KrbMethodNegotiate on > KrbMethodK5Passwd off > KrbServiceName HTTP > KrbAuthRealms GREYOAK.COM > Krb5KeyTab /etc/httpd/conf/ipa.keytab > KrbSaveCredentials on > Require valid-user > ErrorDocument 401 /errors/unauthorized.html > Shouldn't it be Krb5SaveCredentials (note the missing 5 in your conf) ? Have you tried also to set Krb5Forwardable on ? Simo. From rcritten at redhat.com Fri Jul 13 21:26:35 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jul 2007 17:26:35 -0400 Subject: [Freeipa-devel] kerberos ticket forwarding with mod_auth_kerb In-Reply-To: <1184359079.16008.17.camel@localhost.localdomain> References: <4697DE67.5040501@redhat.com> <1184359079.16008.17.camel@localhost.localdomain> Message-ID: <4697EE0B.5010304@redhat.com> Simo Sorce wrote: > On Fri, 2007-07-13 at 16:19 -0400, Rob Crittenden wrote: >> I have mod_auth_kerb configured to save them: >> >> >> AuthType Kerberos >> AuthName "Kerberos Login" >> KrbMethodNegotiate on >> KrbMethodK5Passwd off >> KrbServiceName HTTP >> KrbAuthRealms GREYOAK.COM >> Krb5KeyTab /etc/httpd/conf/ipa.keytab >> KrbSaveCredentials on >> Require valid-user >> ErrorDocument 401 /errors/unauthorized.html >> > > Shouldn't it be Krb5SaveCredentials (note the missing 5 in your conf) ? > Have you tried also to set Krb5Forwardable on ? > > Simo. > I found a patch http://permalink.gmane.org/gmane.comp.apache.mod-auth-kerb.general/980 that seems to work with curl: % curl -u : --negotiate http://ipa.greyoak.com/cgi-bin/klist REMOTE_USER is rcrit at GREYOAK.COM Ticket cache: FILE:/tmp/krb5cc_apache_pOtmOk Default principal: rcrit at GREYOAK.COM Valid starting Expires Service principal 07/13/07 17:21:48 07/14/07 15:56:44 krbtgt/GREYOAK.COM at GREYOAK.COM In Firefox with this patch the cache file is set but klist doesn't report any tickets. So maybe it is a combination of problems. I'll check with the upstream folks. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Fri Jul 13 23:01:23 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 14 Jul 2007 09:01:23 +1000 Subject: [Freeipa-devel] kerberos ticket forwarding with mod_auth_kerb In-Reply-To: <4697EE0B.5010304@redhat.com> References: <4697DE67.5040501@redhat.com> <1184359079.16008.17.camel@localhost.localdomain> <4697EE0B.5010304@redhat.com> Message-ID: <1184367683.5094.35.camel@localhost.localdomain> On Fri, 2007-07-13 at 17:26 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > On Fri, 2007-07-13 at 16:19 -0400, Rob Crittenden wrote: > >> I have mod_auth_kerb configured to save them: > >> > >> > >> AuthType Kerberos > >> AuthName "Kerberos Login" > >> KrbMethodNegotiate on > >> KrbMethodK5Passwd off > >> KrbServiceName HTTP > >> KrbAuthRealms GREYOAK.COM > >> Krb5KeyTab /etc/httpd/conf/ipa.keytab > >> KrbSaveCredentials on > >> Require valid-user > >> ErrorDocument 401 /errors/unauthorized.html > >> > > > > Shouldn't it be Krb5SaveCredentials (note the missing 5 in your conf) ? > > Have you tried also to set Krb5Forwardable on ? > > > > Simo. > > > > I found a patch > http://permalink.gmane.org/gmane.comp.apache.mod-auth-kerb.general/980 > that seems to work with curl: > > % curl -u : --negotiate http://ipa.greyoak.com/cgi-bin/klist > REMOTE_USER is rcrit at GREYOAK.COM > Ticket cache: FILE:/tmp/krb5cc_apache_pOtmOk > Default principal: rcrit at GREYOAK.COM > > Valid starting Expires Service principal > 07/13/07 17:21:48 07/14/07 15:56:44 krbtgt/GREYOAK.COM at GREYOAK.COM > > In Firefox with this patch the cache file is set but klist doesn't > report any tickets. One of the big challenges with forwarded kerberos tickets is that they are almost entirely up to the client - if the client app doesn't really want to give them away, then there is nothing the KDC or target server can do about it... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Fri Jul 13 23:42:47 2007 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 13 Jul 2007 19:42:47 -0400 Subject: [Freeipa-devel] more work on the setup scripts Message-ID: <1184370167.16008.34.camel@localhost.localdomain> If there are no objections I will commit this before leaving on Monday. - patch for fedroa-ds init scripts bz#248169 - create the keytab for the ldap service - create the sample bind zone - test the hostname is set up correctly and resolves to a real IP not 127.0.01 - use the domain portion of the hostname as the DNS domain (ie dns domain may be != realm) - fix the kdb5_ldap_util paramter to actually pass the master password I still have a problem with GSSAPI authentication against LDAP I encoded the same settings I use in my working prototype but SASL auth does not work in the installation test environment. Raising the log level of fedora-ds shows that the sasl mapping object is searched and found, but then fedora-ds tries to find the user account using the wrong filter: (&(uid=)) instead oh (krbPrinciplaName=@) as specified in the configuration. The basedn is correct. Will digg on this later. Simo. -------------- next part -------------- A non-text attachment was scrubbed... Name: freeipa-setup-20070713.patch Type: text/x-patch Size: 10551 bytes Desc: not available URL: From rcritten at redhat.com Sat Jul 14 02:26:07 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Jul 2007 22:26:07 -0400 Subject: [Freeipa-devel] more work on the setup scripts In-Reply-To: <1184370167.16008.34.camel@localhost.localdomain> References: <1184370167.16008.34.camel@localhost.localdomain> Message-ID: <4698343F.5080107@redhat.com> Simo Sorce wrote: > If there are no objections I will commit this before leaving on Monday. > > - patch for fedroa-ds init scripts bz#248169 > - create the keytab for the ldap service > - create the sample bind zone > - test the hostname is set up correctly and resolves to a real IP not > 127.0.01 > - use the domain portion of the hostname as the DNS domain > (ie dns domain may be != realm) > - fix the kdb5_ldap_util paramter to actually pass the master password > > I still have a problem with GSSAPI authentication against LDAP > I encoded the same settings I use in my working prototype but SASL auth > does not work in the installation test environment. > Raising the log level of fedora-ds shows that the sasl mapping object is > searched and found, but then fedora-ds tries to find the user account > using the wrong filter: (&(uid=)) instead oh > (krbPrinciplaName=@) as specified in the configuration. > The basedn is correct. > > Will digg on this later. You set the fedora-ds user as fds. We should probably create that user if it doesn't already exist. Looks like you have a typo when setting the sample DNS zone: bind_fd, bind_name] = tempfile.mkstemp(".db","sammple.zone.") Otherwise it looks ok. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Sun Jul 15 13:56:28 2007 From: ssorce at redhat.com (Simo Sorce) Date: Sun, 15 Jul 2007 09:56:28 -0400 Subject: [Freeipa-devel] more work on the setup scripts In-Reply-To: <4698343F.5080107@redhat.com> References: <1184370167.16008.34.camel@localhost.localdomain> <4698343F.5080107@redhat.com> Message-ID: <1184507788.3402.2.camel@localhost.localdomain> On Fri, 2007-07-13 at 22:26 -0400, Rob Crittenden wrote: > Simo Sorce wrote: > > If there are no objections I will commit this before leaving on Monday. > > > > - patch for fedroa-ds init scripts bz#248169 > > - create the keytab for the ldap service > > - create the sample bind zone > > - test the hostname is set up correctly and resolves to a real IP not > > 127.0.01 > > - use the domain portion of the hostname as the DNS domain > > (ie dns domain may be != realm) > > - fix the kdb5_ldap_util paramter to actually pass the master password > > > > I still have a problem with GSSAPI authentication against LDAP > > I encoded the same settings I use in my working prototype but SASL auth > > does not work in the installation test environment. > > Raising the log level of fedora-ds shows that the sasl mapping object is > > searched and found, but then fedora-ds tries to find the user account > > using the wrong filter: (&(uid=)) instead oh > > (krbPrinciplaName=@) as specified in the configuration. > > The basedn is correct. > > > > Will digg on this later. > > You set the fedora-ds user as fds. We should probably create that user > if it doesn't already exist. We do that, it's in the dsinstance.py module IIRC, I added that bit. > Looks like you have a typo when setting the sample DNS zone: > > bind_fd, bind_name] = tempfile.mkstemp(".db","sammple.zone.") This is strange, this code has been tested and worked. I will check, maybe I touched it after the last test and before generating the diff. > Otherwise it looks ok. Thanks, Simo. From admin at webtuga.com Mon Jul 16 17:27:23 2007 From: admin at webtuga.com (Admin WebTuga) Date: Mon, 16 Jul 2007 18:27:23 +0100 Subject: [Freeipa-devel] Hi! I need to an "about" of the Freeipa project Message-ID: <4a5ef8110707161027n188ee462v400c3bcaf18cd4c@mail.gmail.com> Hi! I need to an "about" of the Freeipa project... i wanna promove it in my blog network. I catched that FreeIPA is a linux distro server wich is prepared with all the basic applications to run a server with logs, management, etc... -------------- next part -------------- An HTML attachment was scrubbed... URL: From prowley at redhat.com Mon Jul 16 17:54:04 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 16 Jul 2007 10:54:04 -0700 Subject: [Freeipa-devel] Hi! I need to an "about" of the Freeipa project In-Reply-To: <4a5ef8110707161027n188ee462v400c3bcaf18cd4c@mail.gmail.com> References: <4a5ef8110707161027n188ee462v400c3bcaf18cd4c@mail.gmail.com> Message-ID: <469BB0BC.9080909@redhat.com> Admin WebTuga wrote: > Hi! I need to an "about" of the Freeipa project... i wanna promove it > in my blog network. > > I catched that FreeIPA is a linux distro server wich is prepared with > all the basic applications to run a server with logs, management, etc... Have you seen freeipa.org ? -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From email.ahmedkamal at googlemail.com Mon Jul 16 18:40:36 2007 From: email.ahmedkamal at googlemail.com (Ahmed Kamal) Date: Mon, 16 Jul 2007 21:40:36 +0300 Subject: [Freeipa-devel] Hook Infrastructure services Message-ID: <3da3b5b40707161140j27ad6a81wa323c55c60d31809@mail.gmail.com> Hi, Since I've heard of the freeipa project, and I've been very excited about it! This kind of "integrated" solution is very much needed in the foss world. IMO, identity servers usually become the heart of a network infrastructure (think AD in a Windows network), basically, something that all services have to integrate with and talk to! That's why I'm wondering if there are current plans to hook essential network services (I think postfix, squid for now) with IPA? Integration would be something like, people's email address, mail quota, authentication, certificates, would be stored in the ldap backend. For squid, I'm thinking about creating some ldap groups (nolimits, needsToEnterPassword, limitedSpeed, NoMP3s ... etc) then assigning users to those ldap groups, and have squid limit/block traffic accroding to such rules. I guess I'm asking if you guys see that as part of the freeipa project, as opposed to something external to your project ?! Personally, I hope you'll provide such infrastructure together with docs on how to configure various servers to hook into your infrastructure. If someone will be working on that, I would be interested to help if I can regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Jul 16 21:02:24 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 16 Jul 2007 17:02:24 -0400 Subject: [Freeipa-devel] another snag with kerberos Message-ID: <469BDCE0.6040007@redhat.com> Found another snag in the forwarding kerberos tickets via XML-RPC: the python xmlrpc library only supports Basic Authentication. The really aggravating part is that as far as I can tell you can't include extra headers to be send in the XMLRPC request, so we can't even include an Authorization header ourselves. And even if we could include our own headers I'm not sure how to hand-craft a Negotiate request. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Mon Jul 16 23:33:44 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Tue, 17 Jul 2007 09:33:44 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469BDCE0.6040007@redhat.com> References: <469BDCE0.6040007@redhat.com> Message-ID: <1184628824.5094.58.camel@localhost.localdomain> On Mon, 2007-07-16 at 17:02 -0400, Rob Crittenden wrote: > Found another snag in the forwarding kerberos tickets via XML-RPC: the > python xmlrpc library only supports Basic Authentication. > > The really aggravating part is that as far as I can tell you can't > include extra headers to be send in the XMLRPC request, so we can't even > include an Authorization header ourselves. > > And even if we could include our own headers I'm not sure how to > hand-craft a Negotiate request. That's the easy part: base64 encode the blob that GSSAPI gives you. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ssorce at redhat.com Tue Jul 17 12:01:17 2007 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 17 Jul 2007 08:01:17 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469BDCE0.6040007@redhat.com> References: <469BDCE0.6040007@redhat.com> Message-ID: <1184673677.32455.0.camel@hopeson> On Mon, 2007-07-16 at 17:02 -0400, Rob Crittenden wrote: > Found another snag in the forwarding kerberos tickets via XML-RPC: the > python xmlrpc library only supports Basic Authentication. > > The really aggravating part is that as far as I can tell you can't > include extra headers to be send in the XMLRPC request, so we can't even > include an Authorization header ourselves. > > And even if we could include our own headers I'm not sure how to > hand-craft a Negotiate request. If it is apache that will serve the contents shouldn't it take care of that? Simo. From rcritten at redhat.com Tue Jul 17 12:23:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jul 2007 08:23:49 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184628824.5094.58.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184628824.5094.58.camel@localhost.localdomain> Message-ID: <469CB4D5.7010209@redhat.com> Andrew Bartlett wrote: > On Mon, 2007-07-16 at 17:02 -0400, Rob Crittenden wrote: >> Found another snag in the forwarding kerberos tickets via XML-RPC: the >> python xmlrpc library only supports Basic Authentication. >> >> The really aggravating part is that as far as I can tell you can't >> include extra headers to be send in the XMLRPC request, so we can't even >> include an Authorization header ourselves. >> >> And even if we could include our own headers I'm not sure how to >> hand-craft a Negotiate request. > > That's the easy part: base64 encode the blob that GSSAPI gives you. > > Perhaps easy to you, someone know GSSAPI. I looked at koji which uses python-krbv and was able to, I think, generate a request, but I'm not sure how to test it. The other thing is that my encoded blob is about 1/3 the size of the blob I see when other clients make successful requests. There is still the problem of ticket forwarding too. Some folks on the mod_auth_kerb mailing list mentioned setting the ok-as-delegate flag. Unfortunately this doesn't seem to be available in MIT kerberos. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Tue Jul 17 13:02:31 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jul 2007 09:02:31 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184673677.32455.0.camel@hopeson> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> Message-ID: <469CBDE7.1000203@redhat.com> Simo Sorce wrote: > On Mon, 2007-07-16 at 17:02 -0400, Rob Crittenden wrote: >> Found another snag in the forwarding kerberos tickets via XML-RPC: the >> python xmlrpc library only supports Basic Authentication. >> >> The really aggravating part is that as far as I can tell you can't >> include extra headers to be send in the XMLRPC request, so we can't even >> include an Authorization header ourselves. >> >> And even if we could include our own headers I'm not sure how to >> hand-craft a Negotiate request. > > If it is apache that will serve the contents shouldn't it take care of > that? > > Simo. > No. Our clients (cli and gui) will include an XMPRPC client. This client needs to authenticate to the XMLRPC server using kerberos. In the GUI this means using a forwarded ticket. In the cli we can probably use the local ccache. In any case, the XMLRPC client will need to include in its request a header that looks something like: Authenticate: Negotiate [insert base64 blob here] I don't see a way to add headers to the client request using xmlrpclib.py. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Tue Jul 17 14:33:40 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 17 Jul 2007 10:33:40 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469CBDE7.1000203@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> Message-ID: <1184682821.15593.6.camel@finch.boston.redhat.com> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: > I don't see a way to add headers to the client request using xmlrpclib.py. I took a quick look at xmlrpclib.py. I agree there does not seem to be a way to add headers in the exported API. However, it's not a complicated module and fairly cleanly written so it looks like it would be relatively easy to edit the the module and add the authentication functionality. This would mean the IPA implementation would have it's own private copy of the module but I suspect once it's working a diff against the original sent as a patch to upstream would be most welcome and then at a later date you can nuke your private copy once upstream ships the fix. -- John Dennis From kmacmill at redhat.com Tue Jul 17 14:35:33 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 17 Jul 2007 10:35:33 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184682821.15593.6.camel@finch.boston.redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> Message-ID: <1184682933.3246.0.camel@localhost.localdomain> On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote: > On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: > > I don't see a way to add headers to the client request using xmlrpclib.py. > > I took a quick look at xmlrpclib.py. I agree there does not seem to be a > way to add headers in the exported API. However, it's not a complicated > module and fairly cleanly written so it looks like it would be > relatively easy to edit the the module and add the authentication > functionality. This would mean the IPA implementation would have it's > own private copy of the module but I suspect once it's working a diff > against the original sent as a patch to upstream would be most welcome > and then at a later date you can nuke your private copy once upstream > ships the fix. Not ideal - but seems workable. Rob - any other options or is this the way you want to go? Karl From rcritten at redhat.com Tue Jul 17 15:00:04 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Jul 2007 11:00:04 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184682933.3246.0.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> Message-ID: <469CD974.3070101@redhat.com> Karl MacMillan wrote: > On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote: >> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: >>> I don't see a way to add headers to the client request using xmlrpclib.py. >> I took a quick look at xmlrpclib.py. I agree there does not seem to be a >> way to add headers in the exported API. However, it's not a complicated >> module and fairly cleanly written so it looks like it would be >> relatively easy to edit the the module and add the authentication >> functionality. This would mean the IPA implementation would have it's >> own private copy of the module but I suspect once it's working a diff >> against the original sent as a patch to upstream would be most welcome >> and then at a later date you can nuke your private copy once upstream >> ships the fix. > > Not ideal - but seems workable. Rob - any other options or is this the > way you want to go? > > Karl > After looking at this some more I wonder if we could simply subclass the Transport method and include the headers that way. I'm not enough of a python expert to know how large a task this would be. In any case we can't do anything until we find a way to do kerberos SSO with ticket forwarding using some sort of HTTP engine. The above would solve the XMLRPC client and server ticket exchange but I still haven't been able to get Apache to forward a ticket from Firefox. I've tried FF 2.0 from FC6 and the native F7 Firefox (in case it was a kerberos library issue). I have FF set to do delegation for the requested URI and according to the logs it seems to be doing it but on the Apache side it isn't caching a ticket. So at this point I'm blocked and need assistance from someone more knowledgeable about kerberos. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Tue Jul 17 15:20:30 2007 From: jdennis at redhat.com (John Dennis) Date: Tue, 17 Jul 2007 11:20:30 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469CD974.3070101@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> Message-ID: <1184685630.15593.16.camel@finch.boston.redhat.com> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > After looking at this some more I wonder if we could simply subclass the > Transport method and include the headers that way. I'm not enough of a > python expert to know how large a task this would be. Yup, I thought about subclassing too but I had noticed there were both a Transport class and a SafeTransport class and the ServerProxy selected which class to use, which would have made subclassing difficult. However, what I missed was there is an optional argument to the ServerProxy constructor which allows passing in a Transport class which can be subclassed nicely. So yes, that does seem like a much better solution. -- John Dennis From rcritten at redhat.com Wed Jul 18 13:18:53 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 09:18:53 -0400 Subject: [Freeipa-devel] [Fwd: Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.] Message-ID: <469E133D.2000301@redhat.com> Does this mean that our forwarding scheme is doomed? Is ok-as-delegate required for us to do what we want? rob -------------- next part -------------- An embedded message was scrubbed... From: Stephen Frost Subject: Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros. Date: Wed, 18 Jul 2007 07:06:12 -0400 Size: 6434 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jul 18 15:48:44 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 11:48:44 -0400 Subject: [Freeipa-devel] LDAP over XML Message-ID: <469E365C.1090909@redhat.com> I've been going back and forth over how much LDAP information to reveal over RPC. At this point it is simply easier to reveal it all (as granted by LDAP ACLs of course). We can remove stuff in the future (like objectclass) but for now I'm going to transmit everything I think. The problem is that on the server side the data is in a raw format. This doesn't work so well with binary fields and you can easily end up with bad data or invalid XML. For the time being I've overridden the string sending of the XML Marshaller to base64 encode everything. Is this price worth paying, to encode and decode all values? We may be able to encode based on attribute but then some user will come along and customize things and their new binary field won't be encoded and things will break. So is this an acceptable trade-off? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Wed Jul 18 15:55:47 2007 From: jdennis at redhat.com (John Dennis) Date: Wed, 18 Jul 2007 11:55:47 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469E365C.1090909@redhat.com> References: <469E365C.1090909@redhat.com> Message-ID: <1184774148.12919.19.camel@junko.usersys.redhat.com> Out of curiosity why are we storing binary data in LDAP and then transmitting binary data through XMLRPC? -- John Dennis From rcritten at redhat.com Wed Jul 18 16:06:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 12:06:49 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <1184774148.12919.19.camel@junko.usersys.redhat.com> References: <469E365C.1090909@redhat.com> <1184774148.12919.19.camel@junko.usersys.redhat.com> Message-ID: <469E3A99.5020609@redhat.com> John Dennis wrote: > Out of curiosity why are we storing binary data in LDAP and then > transmitting binary data through XMLRPC? userCertificate is one candidate A current binary field is krbExtraData rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Wed Jul 18 16:39:55 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 18 Jul 2007 09:39:55 -0700 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469E365C.1090909@redhat.com> References: <469E365C.1090909@redhat.com> Message-ID: <469E425B.6010301@redhat.com> Rob Crittenden wrote: > So is this an acceptable trade-off? > Yes, for now. We will probably need to revisit this, but lets not have it hold us up. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Wed Jul 18 21:33:52 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 17:33:52 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469E365C.1090909@redhat.com> References: <469E365C.1090909@redhat.com> Message-ID: <469E8740.7000504@redhat.com> Rob Crittenden wrote: > I've been going back and forth over how much LDAP information to reveal > over RPC. At this point it is simply easier to reveal it all (as granted > by LDAP ACLs of course). We can remove stuff in the future (like > objectclass) but for now I'm going to transmit everything I think. > > The problem is that on the server side the data is in a raw format. This > doesn't work so well with binary fields and you can easily end up with > bad data or invalid XML. > > For the time being I've overridden the string sending of the XML > Marshaller to base64 encode everything. Is this price worth paying, to > encode and decode all values? > > We may be able to encode based on attribute but then some user will come > along and customize things and their new binary field won't be encoded > and things will break. > > So is this an acceptable trade-off? > Another option we have is I can put the data into LDIF format and return it as one massive stringe. The problem is that I'll have to walk that string and create a dictionary to pluck out individual fields. This might be better since I can then just display stuff without worrying about providing data in a bad format. It might be the lesser of evils. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Wed Jul 18 23:56:34 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 18 Jul 2007 16:56:34 -0700 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469E8740.7000504@redhat.com> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> Message-ID: <469EA8B2.6010200@redhat.com> Rob Crittenden wrote: > > Another option we have is I can put the data into LDIF format and > return it as one massive stringe. I don't think the API should create a parsing problem for clients. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From shaines at redhat.com Thu Jul 19 00:08:31 2007 From: shaines at redhat.com (Scott Haines) Date: Wed, 18 Jul 2007 17:08:31 -0700 Subject: [Freeipa-devel] Questions arising from TSD review Message-ID: <469EAB7F.2040605@redhat.com> http://www.freeipa.com/page/V1PRD From the freeIPA v1.0 PRD: ----------------------- "[Req19.3] Notification of impending expiration. If a user has an email address in their entry it should be possible to configure the IPA server to send notification when passwords are about to expire." ----------------------- How do we intend to implement this? This work doesn't appear to be called out in the schedule. Is this work rolled into another task? ----------------------- " [Req22.3] The Web UI should provide a page that will automatically configure the users browser for Kerberos use within the IPA domain. V1.0 will only provide this functionality for Firefox. IE and Safari will require manual configuration." - and - "[Req9.6] The following client applications should utilize the authentication service of the IPA product. * Firefox - Configured via web page on Administration server." ----------------------- We need to be more specific. What browser versions do we intend to have IPA v1.0 support and what will QE be expected to test against? ~ Scott From prowley at redhat.com Thu Jul 19 00:18:25 2007 From: prowley at redhat.com (Pete Rowley) Date: Wed, 18 Jul 2007 17:18:25 -0700 Subject: [Freeipa-devel] Questions arising from TSD review In-Reply-To: <469EAB7F.2040605@redhat.com> References: <469EAB7F.2040605@redhat.com> Message-ID: <469EADD1.6000904@redhat.com> Scott Haines wrote: > http://www.freeipa.com/page/V1PRD > > From the freeIPA v1.0 PRD: > > ----------------------- > "[Req19.3] Notification of impending expiration. If a user has an > email address in their entry it should be possible to configure the > IPA server to send notification when passwords are about to expire." > ----------------------- > > How do we intend to implement this? It's called out as a plugin but I have reservations about that. Seems like something that would be more safely done as a cron job. > This work doesn't appear to be called out in the schedule. Password Expiry Notification section -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Jul 19 02:00:23 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 19 Jul 2007 12:00:23 +1000 Subject: [Freeipa-devel] [Fwd: Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.] In-Reply-To: <469E133D.2000301@redhat.com> References: <469E133D.2000301@redhat.com> Message-ID: <1184810423.5094.106.camel@localhost.localdomain> On Wed, 2007-07-18 at 09:18 -0400, Rob Crittenden wrote: > Does this mean that our forwarding scheme is doomed? Is ok-as-delegate > required for us to do what we want? Either that, or have firefox and the client configuration pre-configured to get and pass on forwardable tickets by default. I think... The problem that ok-as-delegate was designed to solve is that the client app is entirely the wrong place to have to configure this. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Jul 19 02:07:57 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 22:07:57 -0400 Subject: [Freeipa-devel] [Fwd: Re: [modauthkerb] Negotiate on Windows with cross-realm trust AD and MIT Kereros.] In-Reply-To: <1184810423.5094.106.camel@localhost.localdomain> References: <469E133D.2000301@redhat.com> <1184810423.5094.106.camel@localhost.localdomain> Message-ID: <469EC77D.9080400@redhat.com> Andrew Bartlett wrote: > On Wed, 2007-07-18 at 09:18 -0400, Rob Crittenden wrote: >> Does this mean that our forwarding scheme is doomed? Is ok-as-delegate >> required for us to do what we want? > > Either that, or have firefox and the client configuration pre-configured > to get and pass on forwardable tickets by default. I think... > > The problem that ok-as-delegate was designed to solve is that the client > app is entirely the wrong place to have to configure this. > > Andrew Bartlett > I do have FF set to delegate and trust but either it isn't passing the credentials or mod_auth_kerb isn't getting them or the kerberos libraries are horked. I'm not sure which one. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Jul 19 02:08:39 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 19 Jul 2007 12:08:39 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469CD974.3070101@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> Message-ID: <1184810919.5094.112.camel@localhost.localdomain> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > Karl MacMillan wrote: > > On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote: > >> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: > >>> I don't see a way to add headers to the client request using xmlrpclib.py. > >> I took a quick look at xmlrpclib.py. I agree there does not seem to be a > >> way to add headers in the exported API. However, it's not a complicated > >> module and fairly cleanly written so it looks like it would be > >> relatively easy to edit the the module and add the authentication > >> functionality. This would mean the IPA implementation would have it's > >> own private copy of the module but I suspect once it's working a diff > >> against the original sent as a patch to upstream would be most welcome > >> and then at a later date you can nuke your private copy once upstream > >> ships the fix. > > > > Not ideal - but seems workable. Rob - any other options or is this the > > way you want to go? > > > > Karl > > > > After looking at this some more I wonder if we could simply subclass the > Transport method and include the headers that way. I'm not enough of a > python expert to know how large a task this would be. > > In any case we can't do anything until we find a way to do kerberos SSO > with ticket forwarding using some sort of HTTP engine. Ticket forwarding is on the esoteric end of the kerberos spectrum, and I wonder if for IPAv1 we should instead have the XMLRPC server simply be trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). This would also allow non-kerberos authentication, and remove a pile of complexities that could bite us very badly. For example: Even if we get the forwarded ticket, will it have an address restriction on it? (The mechanism clients have used - dns lookup of target principal - for choosing those addresses have sometimes given very poor results). We could then revisit this later, perhaps combined with KDC modifications to be far less dependent on client behaviour (Heimdal has some very neat solutions, driven by the practical integration needs of the University of Stockholm). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Jul 19 02:13:06 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 22:13:06 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184810919.5094.112.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> Message-ID: <469EC8B2.5000603@redhat.com> Andrew Bartlett wrote: > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: >> Karl MacMillan wrote: >>> On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote: >>>> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: >>>>> I don't see a way to add headers to the client request using xmlrpclib.py. >>>> I took a quick look at xmlrpclib.py. I agree there does not seem to be a >>>> way to add headers in the exported API. However, it's not a complicated >>>> module and fairly cleanly written so it looks like it would be >>>> relatively easy to edit the the module and add the authentication >>>> functionality. This would mean the IPA implementation would have it's >>>> own private copy of the module but I suspect once it's working a diff >>>> against the original sent as a patch to upstream would be most welcome >>>> and then at a later date you can nuke your private copy once upstream >>>> ships the fix. >>> Not ideal - but seems workable. Rob - any other options or is this the >>> way you want to go? >>> >>> Karl >>> >> After looking at this some more I wonder if we could simply subclass the >> Transport method and include the headers that way. I'm not enough of a >> python expert to know how large a task this would be. >> >> In any case we can't do anything until we find a way to do kerberos SSO >> with ticket forwarding using some sort of HTTP engine. > > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > wonder if for IPAv1 we should instead have the XMLRPC server simply be > trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). I'm all in favor of a solution that will work. Do you have any details on how one might do this and whether it is supported by mod_auth_kerb? The way the communication goes is this: Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP So we need some way of grabbing the credentials and passing them all the way to LDAP so we can bind as the user who is logging into Apache. Knowing next-to-nothing about SASL I'm going to need some hand-holding to get this configured and working. > This would also allow non-kerberos authentication, and remove a pile of > complexities that could bite us very badly. For example: Even if we > get the forwarded ticket, will it have an address restriction on it? > (The mechanism clients have used - dns lookup of target principal - for > choosing those addresses have sometimes given very poor results). > > We could then revisit this later, perhaps combined with KDC > modifications to be far less dependent on client behaviour (Heimdal has > some very neat solutions, driven by the practical integration needs of > the University of Stockholm). We're committed to MIT at this point. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Jul 19 02:36:10 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 19 Jul 2007 12:36:10 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469EC8B2.5000603@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> Message-ID: <1184812570.5094.117.camel@localhost.localdomain> On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: > Andrew Bartlett wrote: > > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > >> In any case we can't do anything until we find a way to do kerberos SSO > >> with ticket forwarding using some sort of HTTP engine. > > > > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > > wonder if for IPAv1 we should instead have the XMLRPC server simply be > > trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > > I'm all in favor of a solution that will work. Do you have any details > on how one might do this and whether it is supported by mod_auth_kerb? > > The way the communication goes is this: > > Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP Why do we have the RPC client -> RPC server layer here? > So we need some way of grabbing the credentials and passing them all the > way to LDAP so we can bind as the user who is logging into Apache. > > Knowing next-to-nothing about SASL I'm going to need some hand-holding > to get this configured and working. I suppose I expected (having clearly not followed this enough) that the layers were: User-> web browsser -> Apache/mod_auth_kerb -> LDAP User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP In these cases, you could authenticate the Apache/mod_auth_kerb by simply asserting your identity to LDAP over ldapi:// > > This would also allow non-kerberos authentication, and remove a pile of > > complexities that could bite us very badly. For example: Even if we > > get the forwarded ticket, will it have an address restriction on it? > > (The mechanism clients have used - dns lookup of target principal - for > > choosing those addresses have sometimes given very poor results). > > > > We could then revisit this later, perhaps combined with KDC > > modifications to be far less dependent on client behaviour (Heimdal has > > some very neat solutions, driven by the practical integration needs of > > the University of Stockholm). > > We're committed to MIT at this point. Yeah, while I think that's a poor commitment, it's not one I expect to influence. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rcritten at redhat.com Thu Jul 19 03:02:07 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Jul 2007 23:02:07 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184812570.5094.117.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> Message-ID: <469ED42F.3080807@redhat.com> Andrew Bartlett wrote: > On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: >> Andrew Bartlett wrote: >>> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > >>>> In any case we can't do anything until we find a way to do kerberos SSO >>>> with ticket forwarding using some sort of HTTP engine. >>> Ticket forwarding is on the esoteric end of the kerberos spectrum, and I >>> wonder if for IPAv1 we should instead have the XMLRPC server simply be >>> trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). >> I'm all in favor of a solution that will work. Do you have any details >> on how one might do this and whether it is supported by mod_auth_kerb? >> >> The way the communication goes is this: >> >> Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP > > Why do we have the RPC client -> RPC server layer here? > >> So we need some way of grabbing the credentials and passing them all the >> way to LDAP so we can bind as the user who is logging into Apache. >> >> Knowing next-to-nothing about SASL I'm going to need some hand-holding >> to get this configured and working. > > I suppose I expected (having clearly not followed this enough) that the > layers were: > > User-> web browsser -> Apache/mod_auth_kerb -> LDAP > > User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP The purpose of RPC is to make it very easy for a customer to implement their own GUI. It also lets us do all the hard work once and just glue on a CLI and GUI on top of it. > In these cases, you could authenticate the Apache/mod_auth_kerb by > simply asserting your identity to LDAP over ldapi:// We're supposed to be hiding the fact that LDAP exists. In any case, I'm not sure how I can assert identity if I can't forward the ticket using the browser. >>> This would also allow non-kerberos authentication, and remove a pile of >>> complexities that could bite us very badly. For example: Even if we >>> get the forwarded ticket, will it have an address restriction on it? >>> (The mechanism clients have used - dns lookup of target principal - for >>> choosing those addresses have sometimes given very poor results). >>> >>> We could then revisit this later, perhaps combined with KDC >>> modifications to be far less dependent on client behaviour (Heimdal has >>> some very neat solutions, driven by the practical integration needs of >>> the University of Stockholm). >> We're committed to MIT at this point. > > Yeah, while I think that's a poor commitment, it's not one I expect to > influence. I have no dog in that hunt but I agree. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From abartlet at samba.org Thu Jul 19 03:42:25 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Thu, 19 Jul 2007 13:42:25 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469ED42F.3080807@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <469ED42F.3080807@redhat.com> Message-ID: <1184816545.5094.124.camel@localhost.localdomain> On Wed, 2007-07-18 at 23:02 -0400, Rob Crittenden wrote: > Andrew Bartlett wrote: > > On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: > >> Andrew Bartlett wrote: > >>> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > > > >>>> In any case we can't do anything until we find a way to do kerberos SSO > >>>> with ticket forwarding using some sort of HTTP engine. > >>> Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > >>> wonder if for IPAv1 we should instead have the XMLRPC server simply be > >>> trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > >> I'm all in favor of a solution that will work. Do you have any details > >> on how one might do this and whether it is supported by mod_auth_kerb? > >> > >> The way the communication goes is this: > >> > >> Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP > > > > Why do we have the RPC client -> RPC server layer here? > > > >> So we need some way of grabbing the credentials and passing them all the > >> way to LDAP so we can bind as the user who is logging into Apache. > >> > >> Knowing next-to-nothing about SASL I'm going to need some hand-holding > >> to get this configured and working. > > > > I suppose I expected (having clearly not followed this enough) that the > > layers were: > > > > User-> web browsser -> Apache/mod_auth_kerb -> LDAP > > > > User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP > > The purpose of RPC is to make it very easy for a customer to implement > their own GUI. It also lets us do all the hard work once and just glue > on a CLI and GUI on top of it. > > > In these cases, you could authenticate the Apache/mod_auth_kerb by > > simply asserting your identity to LDAP over ldapi:// > > We're supposed to be hiding the fact that LDAP exists. In any case, I'm > not sure how I can assert identity if I can't forward the ticket using > the browser. Personally, I think trying to hide LDAP is a poor way to start, and a lot of work to implement. Apple did that with their Open Directory, and ended up recreating all the LDAP APIs as open directory APIs. Sure, it let them swap in/out netinfo, but... Similarly in Samba, we have in Samba3 a PDB abstraction, to let us handle the smbpasswd, tdb and ldap backends. In many ways it just created more pain, particularly as we try and use the features of the LDAP backend. I thought that the RPC layer was just to batch up operations that need to be logically combined, but are not just one LDAP operation? Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From etienne.goyer at outlands.ca Thu Jul 19 11:54:46 2007 From: etienne.goyer at outlands.ca (Etienne Goyer) Date: Thu, 19 Jul 2007 07:54:46 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469E8740.7000504@redhat.com> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> Message-ID: <469F5106.1010702@outlands.ca> Hi guys, I'm just a lurker interested in FreeIPA. I do not want to waste your time, but I wonder ... Rob Crittenden wrote: > Rob Crittenden wrote: >> I've been going back and forth over how much LDAP information to >> reveal over RPC. At this point it is simply easier to reveal it all >> (as granted by LDAP ACLs of course). We can remove stuff in the future >> (like objectclass) but for now I'm going to transmit everything I think. Why do "LDAP over XML" in the first place ? Can't the client just query the directory server directly ? This seem very awkward to me. -- Etienne Goyer 0x3106BCC2 "For Bruce Schneier, SHA-1 is merely a compression algorithm." http://geekz.co.uk/schneierfacts/fact/164 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From kmacmill at redhat.com Thu Jul 19 12:49:02 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 08:49:02 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184810919.5094.112.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> Message-ID: <1184849342.26842.2.camel@localhost.localdomain> On Thu, 2007-07-19 at 12:08 +1000, Andrew Bartlett wrote: > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > > Karl MacMillan wrote: > > > On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote: > > >> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: > > >>> I don't see a way to add headers to the client request using xmlrpclib.py. > > >> I took a quick look at xmlrpclib.py. I agree there does not seem to be a > > >> way to add headers in the exported API. However, it's not a complicated > > >> module and fairly cleanly written so it looks like it would be > > >> relatively easy to edit the the module and add the authentication > > >> functionality. This would mean the IPA implementation would have it's > > >> own private copy of the module but I suspect once it's working a diff > > >> against the original sent as a patch to upstream would be most welcome > > >> and then at a later date you can nuke your private copy once upstream > > >> ships the fix. > > > > > > Not ideal - but seems workable. Rob - any other options or is this the > > > way you want to go? > > > > > > Karl > > > > > > > After looking at this some more I wonder if we could simply subclass the > > Transport method and include the headers that way. I'm not enough of a > > python expert to know how large a task this would be. > > > > In any case we can't do anything until we find a way to do kerberos SSO > > with ticket forwarding using some sort of HTTP engine. > > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > wonder if for IPAv1 we should instead have the XMLRPC server simply be > trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > Maybe I don't understand, but are you suggesting that the LDAP database not know the user identity? So the xmlrpc server would connect using a single identity? We got to where we are today because we didn't want to recreate the access control layer that exists in the LDAP server in our xmlrpc server. So if what you're suggesting is the above then I would rather avoid that. Karl From kmacmill at redhat.com Thu Jul 19 12:55:20 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 08:55:20 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184816545.5094.124.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <469ED42F.3080807@redhat.com> <1184816545.5094.124.camel@localhost.localdomain> Message-ID: <1184849720.26842.9.camel@localhost.localdomain> On Thu, 2007-07-19 at 13:42 +1000, Andrew Bartlett wrote: > On Wed, 2007-07-18 at 23:02 -0400, Rob Crittenden wrote: > > Andrew Bartlett wrote: [...] > > > > > In these cases, you could authenticate the Apache/mod_auth_kerb by > > > simply asserting your identity to LDAP over ldapi:// > > > > We're supposed to be hiding the fact that LDAP exists. In any case, I'm > > not sure how I can assert identity if I can't forward the ticket using > > the browser. > > Personally, I think trying to hide LDAP is a poor way to start, and a > lot of work to implement. Apple did that with their Open Directory, and > ended up recreating all the LDAP APIs as open directory APIs. Sure, it > let them swap in/out netinfo, but... > > Similarly in Samba, we have in Samba3 a PDB abstraction, to let us > handle the smbpasswd, tdb and ldap backends. In many ways it just > created more pain, particularly as we try and use the features of the > LDAP backend. > > I thought that the RPC layer was just to batch up operations that need > to be logically combined, but are not just one LDAP operation? > Just to be clear - we are not trying to prevent people from talking to the LDAP server if that is what makes sense for them. By hide we more mean avoid exposing LDAP details in any of the user interfaces that we provide. We are mainly trying to avoid a common problem that I see with GUIs on top of LDAP where all sorts of LDAP details show through (like asking the user for a dn when adding users). We are also planning on providing the xmlrpc layer that makes common operations a little easier than raw LDAP. So I think we are avoiding your concerns by allowing LDAP to be exposed if that is the best way to access the data. Karl From kmacmill at redhat.com Thu Jul 19 13:02:33 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 09:02:33 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184812570.5094.117.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> Message-ID: <1184850153.26842.17.camel@localhost.localdomain> On Thu, 2007-07-19 at 12:36 +1000, Andrew Bartlett wrote: > On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: > > Andrew Bartlett wrote: > > > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > > > >> In any case we can't do anything until we find a way to do kerberos SSO > > >> with ticket forwarding using some sort of HTTP engine. > > > > > > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > > > wonder if for IPAv1 we should instead have the XMLRPC server simply be > > > trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > > > > I'm all in favor of a solution that will work. Do you have any details > > on how one might do this and whether it is supported by mod_auth_kerb? > > > > The way the communication goes is this: > > > > Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP > > Why do we have the RPC client -> RPC server layer here? > > > So we need some way of grabbing the credentials and passing them all the > > way to LDAP so we can bind as the user who is logging into Apache. > > > > Knowing next-to-nothing about SASL I'm going to need some hand-holding > > to get this configured and working. > > I suppose I expected (having clearly not followed this enough) that the > layers were: > > User-> web browsser -> Apache/mod_auth_kerb -> LDAP > > User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP > > In these cases, you could authenticate the Apache/mod_auth_kerb by > simply asserting your identity to LDAP over ldapi:// > Ahh - I see. So on local communications with the LDAP server you can just assert your identity with no authentication. That solves our problem assuming that we can somehow handle the authentication through the web gui to the xmlrpc layer. We could: 1) remove the xmlrpc layer (either entirely or just for the web gui) 2) invent some way to pass who the user is and handle 'local' communication between the gui and xmlrpc layer. We've debated several times whether the xmlrpc layer is truly useful - I like it mainly because it gives a language neutral interface. However, since it is causing a signification amount of complexity (not just this - there is also the API design issues) I suggest we drop it for v1. We can simply use a common python library for the web and commandline interfaces. That should reduce our development time as well. Thoughts? Karl From kmacmill at redhat.com Thu Jul 19 13:11:33 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 09:11:33 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469F5106.1010702@outlands.ca> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> <469F5106.1010702@outlands.ca> Message-ID: <1184850693.26842.24.camel@localhost.localdomain> On Thu, 2007-07-19 at 07:54 -0400, Etienne Goyer wrote: > Hi guys, > > I'm just a lurker interested in FreeIPA. I do not want to waste your > time, but I wonder ... > > Rob Crittenden wrote: > > Rob Crittenden wrote: > >> I've been going back and forth over how much LDAP information to > >> reveal over RPC. At this point it is simply easier to reveal it all > >> (as granted by LDAP ACLs of course). We can remove stuff in the future > >> (like objectclass) but for now I'm going to transmit everything I think. > > Why do "LDAP over XML" in the first place ? Can't the client just query > the directory server directly ? This seem very awkward to me. > I have to agree - as soon as we start passing back ldif we should just go for LDAP queries. Karl From rcritten at redhat.com Thu Jul 19 13:26:58 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jul 2007 09:26:58 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <1184850693.26842.24.camel@localhost.localdomain> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> <469F5106.1010702@outlands.ca> <1184850693.26842.24.camel@localhost.localdomain> Message-ID: <469F66A2.6070906@redhat.com> Karl MacMillan wrote: > On Thu, 2007-07-19 at 07:54 -0400, Etienne Goyer wrote: >> Hi guys, >> >> I'm just a lurker interested in FreeIPA. I do not want to waste your >> time, but I wonder ... >> >> Rob Crittenden wrote: >>> Rob Crittenden wrote: >>>> I've been going back and forth over how much LDAP information to >>>> reveal over RPC. At this point it is simply easier to reveal it all >>>> (as granted by LDAP ACLs of course). We can remove stuff in the future >>>> (like objectclass) but for now I'm going to transmit everything I think. >> Why do "LDAP over XML" in the first place ? Can't the client just query >> the directory server directly ? This seem very awkward to me. >> > > I have to agree - as soon as we start passing back ldif we should just > go for LDAP queries. > Sigh. Look. We have to pass back data to the client somehow right? And the data may be binary which, while supported by RPC, without a schema parser I can't easily identify them (without hardcoding). So I'm passing back a dict of all values returned by a search, the easiest thing to do. Obviously at some point we could restrict it to just the fields requested, not send objectclass, whatever. But it is simply easier to send everything. It is trivial to parse an LDIF into a dict and return that. This way the fields that need to be encoded are encoded and the rest are plain strings. On the receiving side you can do easy stuff like user['cn'] or add a __getattr_ and do user.cn. One advantage that this RPC approach has is writing clients is trivial. I wrote a basic adduser CLI client in about 3 minutes yesterday. A shared library does the same thing for us but is language dependant. I'm not invested in one way or the other but we must decide very soon. Its hard to develop on shifting sands. And remember all this is moot if we can't do forwarded kerberos tickets. At this point I'm completely blocked on it and have moved onto other things that need to be done. It might be a good exercise for someone else to stand up freeipa and try to get basic kerberos working like I did. Then they can stick Apache in the mix and see if they can get forwarding to work in their environment. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Jul 19 13:57:49 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jul 2007 09:57:49 -0400 Subject: [Freeipa-devel] User questions Message-ID: <469F6DDD.3090805@redhat.com> A few questions about adding a user: 1. With our current objectclasses we are required to include cn and sn (but gn is forbidden). In a GUI it is easy to simply ask for first and last name and concatenate them to get cn (and probably use it for gecos too). In a CLI it is a bit awkward to ask for first name. To be luseradd compatible we could require 'gecos' and split that on the first space but that is likely to cause problems. 2. Someone is going to write a uid-generator, right? So I just need to get "get_new_uid()" or something? 3. What should the gid be set to by default? We are creating a group for each user with the same username/uid? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From jdennis at redhat.com Thu Jul 19 14:09:36 2007 From: jdennis at redhat.com (John Dennis) Date: Thu, 19 Jul 2007 10:09:36 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184850153.26842.17.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> Message-ID: <1184854176.14626.34.camel@finch.boston.redhat.com> On Thu, 2007-07-19 at 09:02 -0400, Karl MacMillan wrote: > We've debated several times whether the xmlrpc layer is truly useful - > I like it mainly because it gives a language neutral interface. > However, > since it is causing a signification amount of complexity (not just > this > - there is also the API design issues) I suggest we drop it for v1. We > can simply use a common python library for the web and commandline > interfaces. That should reduce our development time as well. > > Thoughts? I agree, the xmlrpc layer is not serving a sufficiently useful purpose to warrant the costs associated with it. A common library would provide a more expedient solution and possibly a better overall architecture as well. -- John Dennis From abartlet at samba.org Thu Jul 19 14:10:06 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jul 2007 00:10:06 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184849342.26842.2.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <1184849342.26842.2.camel@localhost.localdomain> Message-ID: <1184854206.12216.10.camel@localhost.localdomain> On Thu, 2007-07-19 at 08:49 -0400, Karl MacMillan wrote: > On Thu, 2007-07-19 at 12:08 +1000, Andrew Bartlett wrote: > > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > > > Karl MacMillan wrote: > > > > On Tue, 2007-07-17 at 10:33 -0400, John Dennis wrote: > > > >> On Tue, 2007-07-17 at 09:02 -0400, Rob Crittenden wrote: > > > >>> I don't see a way to add headers to the client request using xmlrpclib.py. > > > >> I took a quick look at xmlrpclib.py. I agree there does not seem to be a > > > >> way to add headers in the exported API. However, it's not a complicated > > > >> module and fairly cleanly written so it looks like it would be > > > >> relatively easy to edit the the module and add the authentication > > > >> functionality. This would mean the IPA implementation would have it's > > > >> own private copy of the module but I suspect once it's working a diff > > > >> against the original sent as a patch to upstream would be most welcome > > > >> and then at a later date you can nuke your private copy once upstream > > > >> ships the fix. > > > > > > > > Not ideal - but seems workable. Rob - any other options or is this the > > > > way you want to go? > > > > > > > > Karl > > > > > > > > > > After looking at this some more I wonder if we could simply subclass the > > > Transport method and include the headers that way. I'm not enough of a > > > python expert to know how large a task this would be. > > > > > > In any case we can't do anything until we find a way to do kerberos SSO > > > with ticket forwarding using some sort of HTTP engine. > > > > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > > wonder if for IPAv1 we should instead have the XMLRPC server simply be > > trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > > > > Maybe I don't understand, but are you suggesting that the LDAP database > not know the user identity? So the xmlrpc server would connect using a > single identity? That's the Samba approach, but no, that's not what I propose. > We got to where we are today because we didn't want to recreate the > access control layer that exists in the LDAP server in our xmlrpc > server. Indeed. > So if what you're suggesting is the above then I would rather > avoid that. If the intermediary can say 'I've proved myself trusted over ldapi://, then use ldap proxy authorization to assert that this operation occurs as . The con is that this intermediary can effectively become any user in the directory (by assertion, if compromised). Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Thu Jul 19 14:13:01 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jul 2007 00:13:01 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184850153.26842.17.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> Message-ID: <1184854381.12216.14.camel@localhost.localdomain> On Thu, 2007-07-19 at 09:02 -0400, Karl MacMillan wrote: > On Thu, 2007-07-19 at 12:36 +1000, Andrew Bartlett wrote: > > On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: > > > Andrew Bartlett wrote: > > > > On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > > > > > >> In any case we can't do anything until we find a way to do kerberos SSO > > > >> with ticket forwarding using some sort of HTTP engine. > > > > > > > > Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > > > > wonder if for IPAv1 we should instead have the XMLRPC server simply be > > > > trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > > > > > > I'm all in favor of a solution that will work. Do you have any details > > > on how one might do this and whether it is supported by mod_auth_kerb? > > > > > > The way the communication goes is this: > > > > > > Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP > > > > Why do we have the RPC client -> RPC server layer here? > > > > > So we need some way of grabbing the credentials and passing them all the > > > way to LDAP so we can bind as the user who is logging into Apache. > > > > > > Knowing next-to-nothing about SASL I'm going to need some hand-holding > > > to get this configured and working. > > > > I suppose I expected (having clearly not followed this enough) that the > > layers were: > > > > User-> web browsser -> Apache/mod_auth_kerb -> LDAP > > > > User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP > > > > In these cases, you could authenticate the Apache/mod_auth_kerb by > > simply asserting your identity to LDAP over ldapi:// > > > > Ahh - I see. So on local communications with the LDAP server you can > just assert your identity with no authentication. Yeah. You could have the EXTERNAL bind prove that you are a trusted uid (process uid), then have the LDAP server configured to allow you to do ldap proxy authorization to any directory user, by assertion. > That solves our problem assuming that we can somehow handle the > authentication through the web gui to the xmlrpc layer. We could: > > 1) remove the xmlrpc layer (either entirely or just for the web gui) > 2) invent some way to pass who the user is and handle 'local' > communication between the gui and xmlrpc layer. > > We've debated several times whether the xmlrpc layer is truly useful - I > like it mainly because it gives a language neutral interface. However, > since it is causing a signification amount of complexity (not just this > - there is also the API design issues) I suggest we drop it for v1. We > can simply use a common python library for the web and commandline > interfaces. That should reduce our development time as well. > > Thoughts? Sounds like a much more sane way to do this for v1... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From abartlet at samba.org Thu Jul 19 14:15:05 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jul 2007 00:15:05 +1000 Subject: [Freeipa-devel] User questions In-Reply-To: <469F6DDD.3090805@redhat.com> References: <469F6DDD.3090805@redhat.com> Message-ID: <1184854505.12216.16.camel@localhost.localdomain> On Thu, 2007-07-19 at 09:57 -0400, Rob Crittenden wrote: > A few questions about adding a user: > > 1. With our current objectclasses we are required to include cn and sn > (but gn is forbidden). In a GUI it is easy to simply ask for first and > last name and concatenate them to get cn (and probably use it for gecos > too). In a CLI it is a bit awkward to ask for first name. To be luseradd > compatible we could require 'gecos' and split that on the first space > but that is likely to cause problems. > > 2. Someone is going to write a uid-generator, right? So I just need to > get "get_new_uid()" or something? You should leave this blank, and before the LDAP server accepts the operation, it will have filled it in with Pete's magical generator (DNA). > 3. What should the gid be set to by default? We are creating a group for > each user with the same username/uid? > > rob > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From rmeggins at redhat.com Thu Jul 19 14:23:09 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 19 Jul 2007 08:23:09 -0600 Subject: [Freeipa-devel] User questions In-Reply-To: <469F6DDD.3090805@redhat.com> References: <469F6DDD.3090805@redhat.com> Message-ID: <469F73CD.4050905@redhat.com> Rob Crittenden wrote: > A few questions about adding a user: > > 1. With our current objectclasses we are required to include cn and sn > (but gn is forbidden). In a GUI it is easy to simply ask for first and > last name and concatenate them to get cn (and probably use it for > gecos too). In a CLI it is a bit awkward to ask for first name. To be > luseradd compatible we could require 'gecos' and split that on the > first space but that is likely to cause problems. > > 2. Someone is going to write a uid-generator, right? So I just need to > get "get_new_uid()" or something? Fedora DS has an auto UID generation plugin. > > 3. What should the gid be set to by default? We are creating a group > for each user with the same username/uid? > > rob > ------------------------------------------------------------------------ > > _______________________________________________ > Freeipa-devel mailing list > Freeipa-devel at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Jul 19 14:38:05 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jul 2007 10:38:05 -0400 Subject: [Freeipa-devel] User questions In-Reply-To: <469F73CD.4050905@redhat.com> References: <469F6DDD.3090805@redhat.com> <469F73CD.4050905@redhat.com> Message-ID: <469F774D.6040101@redhat.com> Richard Megginson wrote: > Rob Crittenden wrote: >> A few questions about adding a user: >> >> 1. With our current objectclasses we are required to include cn and sn >> (but gn is forbidden). In a GUI it is easy to simply ask for first and >> last name and concatenate them to get cn (and probably use it for >> gecos too). In a CLI it is a bit awkward to ask for first name. To be >> luseradd compatible we could require 'gecos' and split that on the >> first space but that is likely to cause problems. >> >> 2. Someone is going to write a uid-generator, right? So I just need to >> get "get_new_uid()" or something? > Fedora DS has an auto UID generation plugin. Ok, wasn't sure if we were going to use that. >> >> 3. What should the gid be set to by default? We are creating a group >> for each user with the same username/uid? >> >> rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Thu Jul 19 16:26:51 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 19 Jul 2007 09:26:51 -0700 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184854206.12216.10.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <1184849342.26842.2.camel@localhost.localdomain> <1184854206.12216.10.camel@localhost.localdomain> Message-ID: <469F90CB.9010203@redhat.com> Andrew Bartlett wrote: > On Thu, 2007-07-19 at 08:49 -0400, Karl MacMillan wrote: > >> So if what you're suggesting is the above then I would rather >> avoid that. >> > > If the intermediary can say 'I've proved myself trusted over ldapi://, > then use ldap proxy authorization to assert that this operation occurs > as . > > I don't think we can rely on ldapi being available. This might be an option in the future, but really I'd rather see kerberos work the way it is supposed to. > The con is that this intermediary can effectively become any user in the > directory (by assertion, if compromised). > This is why we went down the kerberos forwardable ticket route. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Thu Jul 19 16:55:39 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 19 Jul 2007 09:55:39 -0700 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184850153.26842.17.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> Message-ID: <469F978B.4030401@redhat.com> Karl MacMillan wrote: > On Thu, 2007-07-19 at 12:36 +1000, Andrew Bartlett wrote: > >> On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: >> >>> Andrew Bartlett wrote: >>> >>>> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: >>>> >>>>> In any case we can't do anything until we find a way to do kerberos SSO >>>>> with ticket forwarding using some sort of HTTP engine. >>>>> >>>> Ticket forwarding is on the esoteric end of the kerberos spectrum, and I >>>> wonder if for IPAv1 we should instead have the XMLRPC server simply be >>>> trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). >>>> >>> I'm all in favor of a solution that will work. Do you have any details >>> on how one might do this and whether it is supported by mod_auth_kerb? >>> >>> The way the communication goes is this: >>> >>> Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP >>> >> Why do we have the RPC client -> RPC server layer here? >> >> >>> So we need some way of grabbing the credentials and passing them all the >>> way to LDAP so we can bind as the user who is logging into Apache. >>> >>> Knowing next-to-nothing about SASL I'm going to need some hand-holding >>> to get this configured and working. >>> >> I suppose I expected (having clearly not followed this enough) that the >> layers were: >> >> User-> web browsser -> Apache/mod_auth_kerb -> LDAP >> >> User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP >> >> In these cases, you could authenticate the Apache/mod_auth_kerb by >> simply asserting your identity to LDAP over ldapi:// >> >> > > Ahh - I see. So on local communications with the LDAP server you can > just assert your identity with no authentication. > Kinda, except that we cannot rely upon ldapi being available i.e. we can't use it. I added it to FDS earlier this year but it won't have filtered through in time for us I'm afraid. However, it is not required that ldapi is used in order to take advantage of LDAP proxy authentication - but we are left with a credential problem we didn't have before. System level authentication using ldapi is definitely neater. > That solves our problem assuming that we can somehow handle the > authentication through the web gui to the xmlrpc layer. We could: > > 1) remove the xmlrpc layer (either entirely or just for the web gui) > > 2) invent some way to pass who the user is and handle 'local' > communication between the gui and xmlrpc layer. > > We've debated several times whether the xmlrpc layer is truly useful - I > like it mainly because it gives a language neutral interface. However, > since it is causing a signification amount of complexity (not just this > - there is also the API design issues) I suggest we drop it for v1. We > can simply use a common python library for the web and commandline > interfaces. That should reduce our development time as well. > > Thoughts? > As devil's advocate I feel compelled to point out that an approach that places the system logic into client libraries (rather than on the server) runs the risk of much more resistance to change in the future, since now that change has a greater and more far reaching impact: clients get built, sold, and generally hang around being a nuisance. Language neutral is also a big win. At this point though, we need something that works now. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Thu Jul 19 17:04:34 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 13:04:34 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469F978B.4030401@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> <469F978B.4030401@redhat.com> Message-ID: <1184864674.26842.29.camel@localhost.localdomain> On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote: > Karl MacMillan wrote: > > On Thu, 2007-07-19 at 12:36 +1000, Andrew Bartlett wrote: > > > >> On Wed, 2007-07-18 at 22:13 -0400, Rob Crittenden wrote: > >> > >>> Andrew Bartlett wrote: > >>> > >>>> On Tue, 2007-07-17 at 11:00 -0400, Rob Crittenden wrote: > >>>> > >>>>> In any case we can't do anything until we find a way to do kerberos SSO > >>>>> with ticket forwarding using some sort of HTTP engine. > >>>>> > >>>> Ticket forwarding is on the esoteric end of the kerberos spectrum, and I > >>>> wonder if for IPAv1 we should instead have the XMLRPC server simply be > >>>> trusted? (Bind as EXTERNAL, then do LDAP proxy authorization). > >>>> > >>> I'm all in favor of a solution that will work. Do you have any details > >>> on how one might do this and whether it is supported by mod_auth_kerb? > >>> > >>> The way the communication goes is this: > >>> > >>> Web -> Apache/mod_auth_kerb -> RPC client -> RPC server -> LDAP > >>> > >> Why do we have the RPC client -> RPC server layer here? > >> > >> > >>> So we need some way of grabbing the credentials and passing them all the > >>> way to LDAP so we can bind as the user who is logging into Apache. > >>> > >>> Knowing next-to-nothing about SASL I'm going to need some hand-holding > >>> to get this configured and working. > >>> > >> I suppose I expected (having clearly not followed this enough) that the > >> layers were: > >> > >> User-> web browsser -> Apache/mod_auth_kerb -> LDAP > >> > >> User -> command-line-tool -> Apache/mod_auth_kerb -> LDAP > >> > >> In these cases, you could authenticate the Apache/mod_auth_kerb by > >> simply asserting your identity to LDAP over ldapi:// > >> > >> > > > > Ahh - I see. So on local communications with the LDAP server you can > > just assert your identity with no authentication. > > > Kinda, except that we cannot rely upon ldapi being available i.e. we > can't use it. I added it to FDS earlier this year but it won't have > filtered through in time for us I'm afraid. In previous discussions I thought we had decided that it would be available if we were willing to assume the testing burden. > However, it is not required > that ldapi is used in order to take advantage of LDAP proxy > authentication - but we are left with a credential problem we didn't > have before. System level authentication using ldapi is definitely neater. And seems like the correct solution to me. > > That solves our problem assuming that we can somehow handle the > > authentication through the web gui to the xmlrpc layer. We could: > > > > 1) remove the xmlrpc layer (either entirely or just for the web gui) > > > > 2) invent some way to pass who the user is and handle 'local' > > communication between the gui and xmlrpc layer. > > > > We've debated several times whether the xmlrpc layer is truly useful - I > > like it mainly because it gives a language neutral interface. However, > > since it is causing a signification amount of complexity (not just this > > - there is also the API design issues) I suggest we drop it for v1. We > > can simply use a common python library for the web and commandline > > interfaces. That should reduce our development time as well. > > > > Thoughts? > > > As devil's advocate I feel compelled to point out that an approach that > places the system logic into client libraries (rather than on the > server) runs the risk of much more resistance to change in the future, > since now that change has a greater and more far reaching impact: > clients get built, sold, and generally hang around being a nuisance. > > Language neutral is also a big win. > > At this point though, we need something that works now. > Agreed on all 3 points - which is why I suggested it :) I think this is a short-term architectural decision not a long term one. Karl From kmacmill at redhat.com Thu Jul 19 17:28:15 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 13:28:15 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469F66A2.6070906@redhat.com> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> <469F5106.1010702@outlands.ca> <1184850693.26842.24.camel@localhost.localdomain> <469F66A2.6070906@redhat.com> Message-ID: <1184866095.3136.3.camel@localhost.localdomain> On Thu, 2007-07-19 at 09:26 -0400, Rob Crittenden wrote: > Karl MacMillan wrote: > > On Thu, 2007-07-19 at 07:54 -0400, Etienne Goyer wrote: > >> Hi guys, > >> > >> I'm just a lurker interested in FreeIPA. I do not want to waste your > >> time, but I wonder ... > >> > >> Rob Crittenden wrote: > >>> Rob Crittenden wrote: > >>>> I've been going back and forth over how much LDAP information to > >>>> reveal over RPC. At this point it is simply easier to reveal it all > >>>> (as granted by LDAP ACLs of course). We can remove stuff in the future > >>>> (like objectclass) but for now I'm going to transmit everything I think. > >> Why do "LDAP over XML" in the first place ? Can't the client just query > >> the directory server directly ? This seem very awkward to me. > >> > > > > I have to agree - as soon as we start passing back ldif we should just > > go for LDAP queries. > > > > Sigh. Look. We have to pass back data to the client somehow right? And > the data may be binary which, while supported by RPC, without a schema > parser I can't easily identify them (without hardcoding). > > So I'm passing back a dict of all values returned by a search, the > easiest thing to do. Obviously at some point we could restrict it to > just the fields requested, not send objectclass, whatever. But it is > simply easier to send everything. > > It is trivial to parse an LDIF into a dict and return that. This way the > fields that need to be encoded are encoded and the rest are plain > strings. On the receiving side you can do easy stuff like user['cn'] or > add a __getattr_ and do user.cn. > So in that scheme the LDIF parsing is server side? > One advantage that this RPC approach has is writing clients is trivial. > I wrote a basic adduser CLI client in about 3 minutes yesterday. A > shared library does the same thing for us but is language dependant. I'm > not invested in one way or the other but we must decide very soon. Its > hard to develop on shifting sands. > Definitely on all points. > And remember all this is moot if we can't do forwarded kerberos tickets. > At this point I'm completely blocked on it and have moved onto other > things that need to be done. It might be a good exercise for someone > else to stand up freeipa and try to get basic kerberos working like I > did. Then they can stick Apache in the mix and see if they can get > forwarding to work in their environment. > Right - so it seems everyone agrees that the forwarded tickets and xml-rpc layer would be nice, but like you said we need to make forward progress. Let's push on the ticket forwarding today and tomorrow (and pull in some help from upstream / others). If we haven't resolved it by then I vote for going to the library solution plus ldapi. Karl > rob From kmacmill at redhat.com Thu Jul 19 17:34:30 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 13:34:30 -0400 Subject: [Freeipa-devel] Hook Infrastructure services In-Reply-To: <3da3b5b40707161140j27ad6a81wa323c55c60d31809@mail.gmail.com> References: <3da3b5b40707161140j27ad6a81wa323c55c60d31809@mail.gmail.com> Message-ID: <1184866470.3136.10.camel@localhost.localdomain> On Mon, 2007-07-16 at 21:40 +0300, Ahmed Kamal wrote: > Hi, > Since I've heard of the freeipa project, and I've been very excited > about it! This kind of "integrated" solution is very much needed in > the foss world. IMO, identity servers usually become the heart of a > network infrastructure (think AD in a Windows network), basically, > something that all services have to integrate with and talk to! > > That's why I'm wondering if there are current plans to hook essential > network services (I think postfix, squid for now) with IPA? > Integration would be something like, people's email address, mail > quota, authentication, certificates, would be stored in the ldap > backend. For squid, I'm thinking about creating some ldap groups > (nolimits, needsToEnterPassword, limitedSpeed, NoMP3s ... etc) then > assigning users to those ldap groups, and have squid limit/block > traffic accroding to such rules. > > I guess I'm asking if you guys see that as part of the freeipa > project, as opposed to something external to your project ?! > Personally, I hope you'll provide such infrastructure together with > docs on how to configure various servers to hook into your > infrastructure. If someone will be working on that, I would be > interested to help if I can > I'm glad that you are excited about making it simple for other solutions to use freeipa data - that is definitely something we are hoping will happen. To your specific question of whether that kind of work is in scope for freeipa, I would say that we want to enable that without pulling all of that under the same project umbrella. For example, we would like to make it possible for the kind of configuration you describe to happen in the same management console as the rest of freeipa (same infrastructure, auth, etc.). Perhaps through some plugin mechanism. So if you are willing, as we get the gui up and running perhaps you could look for ways to make are tools extensible for your needs. Thanks - Karl From prowley at redhat.com Thu Jul 19 17:44:16 2007 From: prowley at redhat.com (Pete Rowley) Date: Thu, 19 Jul 2007 10:44:16 -0700 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184864674.26842.29.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> <469F978B.4030401@redhat.com> <1184864674.26842.29.camel@localhost.localdomain> Message-ID: <469FA2F0.90201@redhat.com> Karl MacMillan wrote: > On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote: > > > In previous discussions I thought we had decided that it would be > available if we were willing to assume the testing burden. > > I don't recall that specifically for this but if we need it it needs to be compiled in e.g. in RHDS 8.0 which almost certainly doesn't right now, it isn't in a plugin, it is core. > Agreed on all 3 points - which is why I suggested it :) I think this is > a short-term architectural decision not a long term one. > > I am pointing out that it isn't so short term and as such we need to go in with eyes wide open. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Thu Jul 19 18:02:30 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jul 2007 14:02:30 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <1184866095.3136.3.camel@localhost.localdomain> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> <469F5106.1010702@outlands.ca> <1184850693.26842.24.camel@localhost.localdomain> <469F66A2.6070906@redhat.com> <1184866095.3136.3.camel@localhost.localdomain> Message-ID: <469FA736.5010608@redhat.com> Karl MacMillan wrote: > On Thu, 2007-07-19 at 09:26 -0400, Rob Crittenden wrote: >> Karl MacMillan wrote: >>> On Thu, 2007-07-19 at 07:54 -0400, Etienne Goyer wrote: >>>> Hi guys, >>>> >>>> I'm just a lurker interested in FreeIPA. I do not want to waste your >>>> time, but I wonder ... >>>> >>>> Rob Crittenden wrote: >>>>> Rob Crittenden wrote: >>>>>> I've been going back and forth over how much LDAP information to >>>>>> reveal over RPC. At this point it is simply easier to reveal it all >>>>>> (as granted by LDAP ACLs of course). We can remove stuff in the future >>>>>> (like objectclass) but for now I'm going to transmit everything I think. >>>> Why do "LDAP over XML" in the first place ? Can't the client just query >>>> the directory server directly ? This seem very awkward to me. >>>> >>> I have to agree - as soon as we start passing back ldif we should just >>> go for LDAP queries. >>> >> Sigh. Look. We have to pass back data to the client somehow right? And >> the data may be binary which, while supported by RPC, without a schema >> parser I can't easily identify them (without hardcoding). >> >> So I'm passing back a dict of all values returned by a search, the >> easiest thing to do. Obviously at some point we could restrict it to >> just the fields requested, not send objectclass, whatever. But it is >> simply easier to send everything. >> >> It is trivial to parse an LDIF into a dict and return that. This way the >> fields that need to be encoded are encoded and the rest are plain >> strings. On the receiving side you can do easy stuff like user['cn'] or >> add a __getattr_ and do user.cn. >> > > So in that scheme the LDIF parsing is server side? Right. >> One advantage that this RPC approach has is writing clients is trivial. >> I wrote a basic adduser CLI client in about 3 minutes yesterday. A >> shared library does the same thing for us but is language dependant. I'm >> not invested in one way or the other but we must decide very soon. Its >> hard to develop on shifting sands. >> > > Definitely on all points. > >> And remember all this is moot if we can't do forwarded kerberos tickets. >> At this point I'm completely blocked on it and have moved onto other >> things that need to be done. It might be a good exercise for someone >> else to stand up freeipa and try to get basic kerberos working like I >> did. Then they can stick Apache in the mix and see if they can get >> forwarding to work in their environment. >> > > Right - so it seems everyone agrees that the forwarded tickets and > xml-rpc layer would be nice, but like you said we need to make forward > progress. Let's push on the ticket forwarding today and tomorrow (and > pull in some help from upstream / others). If we haven't resolved it by > then I vote for going to the library solution plus ldapi. How does ldapi helps us? Who will it bind as? rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Thu Jul 19 18:06:14 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 14:06:14 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <469FA736.5010608@redhat.com> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> <469F5106.1010702@outlands.ca> <1184850693.26842.24.camel@localhost.localdomain> <469F66A2.6070906@redhat.com> <1184866095.3136.3.camel@localhost.localdomain> <469FA736.5010608@redhat.com> Message-ID: <1184868374.3136.16.camel@localhost.localdomain> On Thu, 2007-07-19 at 14:02 -0400, Rob Crittenden wrote: > Karl MacMillan wrote: > > On Thu, 2007-07-19 at 09:26 -0400, Rob Crittenden wrote: [...] > > > >> And remember all this is moot if we can't do forwarded kerberos tickets. > >> At this point I'm completely blocked on it and have moved onto other > >> things that need to be done. It might be a good exercise for someone > >> else to stand up freeipa and try to get basic kerberos working like I > >> did. Then they can stick Apache in the mix and see if they can get > >> forwarding to work in their environment. > >> > > > > Right - so it seems everyone agrees that the forwarded tickets and > > xml-rpc layer would be nice, but like you said we need to make forward > > progress. Let's push on the ticket forwarding today and tomorrow (and > > pull in some help from upstream / others). If we haven't resolved it by > > then I vote for going to the library solution plus ldapi. > > How does ldapi helps us? Who will it bind as? > >From Andrew's mails it appears possible to bind as any user - the web layer would be a trusted proxy. For the command line tools they would just speak ldap and use a normal kerberos bind. It helps because it removes the need for forwarded tickets - it would only require normal tickets. Karl > rob From rcritten at redhat.com Thu Jul 19 18:21:59 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Jul 2007 14:21:59 -0400 Subject: [Freeipa-devel] LDAP over XML In-Reply-To: <1184868374.3136.16.camel@localhost.localdomain> References: <469E365C.1090909@redhat.com> <469E8740.7000504@redhat.com> <469F5106.1010702@outlands.ca> <1184850693.26842.24.camel@localhost.localdomain> <469F66A2.6070906@redhat.com> <1184866095.3136.3.camel@localhost.localdomain> <469FA736.5010608@redhat.com> <1184868374.3136.16.camel@localhost.localdomain> Message-ID: <469FABC7.80703@redhat.com> Karl MacMillan wrote: > On Thu, 2007-07-19 at 14:02 -0400, Rob Crittenden wrote: >> Karl MacMillan wrote: >>> On Thu, 2007-07-19 at 09:26 -0400, Rob Crittenden wrote: > [...] >>>> And remember all this is moot if we can't do forwarded kerberos tickets. >>>> At this point I'm completely blocked on it and have moved onto other >>>> things that need to be done. It might be a good exercise for someone >>>> else to stand up freeipa and try to get basic kerberos working like I >>>> did. Then they can stick Apache in the mix and see if they can get >>>> forwarding to work in their environment. >>>> >>> Right - so it seems everyone agrees that the forwarded tickets and >>> xml-rpc layer would be nice, but like you said we need to make forward >>> progress. Let's push on the ticket forwarding today and tomorrow (and >>> pull in some help from upstream / others). If we haven't resolved it by >>> then I vote for going to the library solution plus ldapi. >> How does ldapi helps us? Who will it bind as? >> > >>From Andrew's mails it appears possible to bind as any user - the web > layer would be a trusted proxy. For the command line tools they would > just speak ldap and use a normal kerberos bind. > > It helps because it removes the need for forwarded tickets - it would > only require normal tickets. > Well, ok, if I understand this we don't have to link the XML-RPC stuff with forwarded tickets. If we have the XML-RPC server do the proxy authentication AND we make sure that Apache authenticates all requests with kerberos we should be ok. My head hurts. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Thu Jul 19 22:03:59 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 18:03:59 -0400 Subject: [Freeipa-devel] Additional debugging Message-ID: <1184882639.3120.1.camel@localhost.localdomain> I've committed the attached patch to help with debugging. It adds a -d flag to print debugging information on the console and adds some additional debugging statements. -------------- next part -------------- A non-text attachment was scrubbed... Name: debug.diff Type: text/x-patch Size: 4525 bytes Desc: not available URL: From kmacmill at redhat.com Thu Jul 19 22:04:35 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Thu, 19 Jul 2007 18:04:35 -0400 Subject: [Freeipa-devel] more work on the setup scripts In-Reply-To: <1184507788.3402.2.camel@localhost.localdomain> References: <1184370167.16008.34.camel@localhost.localdomain> <4698343F.5080107@redhat.com> <1184507788.3402.2.camel@localhost.localdomain> Message-ID: <1184882675.3120.3.camel@localhost.localdomain> On Sun, 2007-07-15 at 09:56 -0400, Simo Sorce wrote: > On Fri, 2007-07-13 at 22:26 -0400, Rob Crittenden wrote: > > Simo Sorce wrote: > > > If there are no objections I will commit this before leaving on Monday. > > > > > > - patch for fedroa-ds init scripts bz#248169 > > > - create the keytab for the ldap service > > > - create the sample bind zone > > > - test the hostname is set up correctly and resolves to a real IP not > > > 127.0.01 > > > - use the domain portion of the hostname as the DNS domain > > > (ie dns domain may be != realm) > > > - fix the kdb5_ldap_util paramter to actually pass the master password > > > > > > I still have a problem with GSSAPI authentication against LDAP > > > I encoded the same settings I use in my working prototype but SASL auth > > > does not work in the installation test environment. > > > Raising the log level of fedora-ds shows that the sasl mapping object is > > > searched and found, but then fedora-ds tries to find the user account > > > using the wrong filter: (&(uid=)) instead oh > > > (krbPrinciplaName=@) as specified in the configuration. > > > The basedn is correct. > > > > > > Will digg on this later. > > > > You set the fedora-ds user as fds. We should probably create that user > > if it doesn't already exist. > > We do that, it's in the dsinstance.py module IIRC, I added that bit. > > > Looks like you have a typo when setting the sample DNS zone: > > > > bind_fd, bind_name] = tempfile.mkstemp(".db","sammple.zone.") > > This is strange, this code has been tested and worked. I will check, > maybe I touched it after the last test and before generating the diff. > > > Otherwise it looks ok. > I committed the attached modified version of this patch. Karl -------------- next part -------------- [?1034hdiff -r 3a76f9007b34 ipa-install/README --- a/ipa-install/README Wed Jul 18 14:34:40 2007 -0400 +++ b/ipa-install/README Thu Jul 19 14:35:34 2007 -0400 @@ -5,12 +5,17 @@ fedora-ds-base fedora-ds-base openldap-clients krb5-server-ldap +cyrus-sasl-gssapi Installation example: + +TEMPORARY: (until fedora ds scripts are fixed) +please use the fedora-ds.init.patch under share/ to patch your init scripts before +running ipa-server-install cd ipa-install make install cd .. -/usr/sbin/ipa-server-install -r FREEIPA.ORG -a rc1.freeipa.org -p freeipa -m ipafree +/usr/sbin/ipa-server-install -u fds -r FREEIPA.ORG -p freeipa -m ipafree diff -r 3a76f9007b34 ipa-install/share/bind.zone.db.template --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-install/share/bind.zone.db.template Thu Jul 19 14:35:34 2007 -0400 @@ -0,0 +1,26 @@ +$$ORIGIN $DOMAIN. +$$TTL 86400 +@ IN SOA $DOMAIN. root.$DOMAIN. ( + 01 ; serial (d. adams) + 3H ; refresh + 15M ; retry + 1W ; expiry + 1D ) ; minimum + + IN NS $HOST +$HOST IN A $IP +; +; ldap servers +_ldap._tcp IN SRV 0 100 389 $HOST + +;kerberos realm +_kerberos IN TXT $REALM + +; kerberos servers +_kerberos._tcp IN SRV 0 100 88 $HOST +_kerberos._udp IN SRV 0 100 88 $HOST +_kerberos-master._tcp IN SRV 0 100 88 $HOST +_kerberos-master._udp IN SRV 0 100 88 $HOST +_kpasswd._tcp IN SRV 0 100 88 $HOST +_kpasswd._udp IN SRV 0 100 88 $HOST + diff -r 3a76f9007b34 ipa-install/share/fedora-ds.init.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/ipa-install/share/fedora-ds.init.patch Thu Jul 19 14:35:34 2007 -0400 @@ -0,0 +1,12 @@ +--- /etc/init.d/fedora-ds.orig 2007-07-06 18:21:30.000000000 -0400 ++++ /etc/init.d/fedora-ds 2007-05-18 19:36:24.000000000 -0400 +@@ -10,6 +10,9 @@ + # datadir: /var/lib/fedora-ds/slapd- + # + ++# Get config. ++[ -r /etc/sysconfig/fedora-ds ] && . /etc/sysconfig/fedora-ds ++ + # Source function library. + if [ -f /etc/rc.d/init.d/functions ] ; then + . /etc/rc.d/init.d/functions diff -r 3a76f9007b34 ipa-install/share/krb5.conf.template --- a/ipa-install/share/krb5.conf.template Wed Jul 18 14:34:40 2007 -0400 +++ b/ipa-install/share/krb5.conf.template Thu Jul 19 14:35:34 2007 -0400 @@ -9,6 +9,13 @@ dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes + +[realms] + $REALM = { + kdc = $FQDN:88 + admin_server = $FQDN:749 + default_domain = $DOMAIN +} [domain_realm] .$DOMAIN = $REALM @@ -29,7 +36,7 @@ ldap_servers = ldap://127.0.0.1/ ldap_kerberos_container_dn = cn=kerberos,$SUFFIX ldap_kdc_dn = uid=kdc,cn=kerberos,$SUFFIX -; ldap_kadmind_dn = cn=Directory Manager + ldap_kadmind_dn = uid=kdc,cn=kerberos,$SUFFIX ldap_service_password_file = /var/kerberos/krb5kdc/ldappwd } diff -r 3a76f9007b34 ipa-install/src/ipa-server-install --- a/ipa-install/src/ipa-server-install Wed Jul 18 14:34:40 2007 -0400 +++ b/ipa-install/src/ipa-server-install Thu Jul 19 15:09:10 2007 -0400 @@ -26,6 +26,7 @@ VERSION = "%prog .1" +import socket import logging from optparse import OptionParser import ipa.dsinstance @@ -37,19 +38,18 @@ def parse_options(): help="ds user") parser.add_option("-r", "--realm", dest="realm_name", help="realm name") - parser.add_option("-a", "--host-address", dest="host_name", - help="host address (name or IP address)") parser.add_option("-p", "--password", dest="password", help="admin password") parser.add_option("-m", "--master-password", dest="master_password", help="kerberos master password") parser.add_option("-d", "--debug", dest="debug", action="store_true", dest="debug", default=False, help="print debugging information") + parser.add_option("--hostname", dest="host_name", help="fully qualified name of server") options, args = parser.parse_args() - if not options.realm_name or not options.host_name or not options.password: - parser.error("error: password, realm, and host name required") + if not options.ds_user or not options.realm_name or not options.password or not options.master_password: + parser.error("error: all options are required") return options @@ -76,13 +76,39 @@ def main(): options = parse_options() logging_setup(options) + # check the hostname is correctly configured, it must be as the kldap + # utilities just use the hostname as returned by gethostbyname to set + # up some of the standard entries + + if options.host_name: + host_name = options.host_name + else: + host_name = socket.gethostname() + if len(host_name.split(".")) < 2: + print "Invalid hostname <"+host_name+">" + print "Check the /etc/hosts file and make sure to have a valid FQDN" + return "-Fatal Error-" + + if socket.gethostbyname(host_name) == "127.0.0.1": + print "The hostname resolves to the localhost address (127.0.0.1)" + print "Please change your /etc/hosts file or your DNS so that the" + print "hostname resolves to the ip address of your network interface." + print "The KDC service does not listen on 127.0.0.1" + return "-Fatal Error-" + + print "The Final KDC Host Name will be: " + host_name + + # Create a directory server instance ds = ipa.dsinstance.DsInstance() - ds.create_instance(options.ds_user, options.realm_name, options.host_name, options.password) + ds.create_instance(options.ds_user, options.realm_name, host_name, + options.password) # Create a kerberos instance krb = ipa.krbinstance.KrbInstance() - krb.create_instance(options.ds_user, options.realm_name, options.host_name, options.password, options.master_password) + krb.create_instance(options.ds_user, options.realm_name, host_name, + options.password, options.master_password) + #restart ds after the krb instance have add the sasl map ds.restart() diff -r 3a76f9007b34 ipa-install/src/ipa/krbinstance.py --- a/ipa-install/src/ipa/krbinstance.py Wed Jul 18 14:34:40 2007 -0400 +++ b/ipa-install/src/ipa/krbinstance.py Thu Jul 19 15:01:40 2007 -0400 @@ -25,6 +25,9 @@ import logging import logging from random import Random from time import gmtime +import os +import pwd +import socket SHARE_DIR = "/usr/share/ipa/" @@ -32,6 +35,10 @@ def realm_to_suffix(realm_name): s = realm_name.split(".") terms = ["dc=" + x.lower() for x in s] return ",".join(terms) + +def host_to_domain(fqdn): + s = fqdn.split(".") + return ".".join(s[1:]) def generate_kdc_password(): rndpwd = '' @@ -75,8 +82,10 @@ class KrbInstance: class KrbInstance: def __init__(self): self.ds_user = None - self.realm_name = None - self.host_name = None + self.fqdn = None + self.realm = None + self.domain = None + self.host = None self.admin_password = None self.master_password = None self.suffix = None @@ -85,12 +94,15 @@ class KrbInstance: def create_instance(self, ds_user, realm_name, host_name, admin_password, master_password): self.ds_user = ds_user - self.realm_name = realm_name.upper() - self.host_name = host_name + self.fqdn = host_name + self.ip = socket.gethostbyname(host_name) + self.realm = realm_name.upper() + self.host = host_name.split(".")[0] + self.domain = host_to_domain(host_name) self.admin_password = admin_password self.master_password = master_password - self.suffix = realm_to_suffix(self.realm_name) + self.suffix = realm_to_suffix(self.realm) self.kdc_password = generate_kdc_password() self.__configure_kdc_account_password() @@ -99,6 +111,10 @@ class KrbInstance: self.__configure_ldap() self.__create_instance() + + self.__create_ds_keytab() + + self.__create_sample_bind_zone() self.start() @@ -120,12 +136,13 @@ class KrbInstance: pwd_fd.close() def __setup_sub_dict(self): - #FIXME: can DOMAIN be different than REALM ? - self.sub_dict = dict(FQHN=self.host_name, + self.sub_dict = dict(FQDN=self.fqdn, + IP=self.ip, PASSWORD=self.kdc_password, SUFFIX=self.suffix, - DOMAIN= self.realm_name.lower(), - REALM=self.realm_name) + DOMAIN=self.domain, + HOST=self.host, + REALM=self.realm) def __configure_ldap(self): @@ -153,7 +170,7 @@ class KrbInstance: krb5_fd.close() #populate the directory with the realm structure - args = ["/usr/kerberos/sbin/kdb5_ldap_util", "-D", "uid=kdc,cn=kerberos,"+self.suffix, "-w", self.kdc_password, "create", "-s", "-r", self.realm_name, "-subtrees", self.suffix, "-sscope", "sub"] + args = ["/usr/kerberos/sbin/kdb5_ldap_util", "-D", "uid=kdc,cn=kerberos,"+self.suffix, "-w", self.kdc_password, "create", "-s", "-P", self.master_password, "-r", self.realm, "-subtrees", self.suffix, "-sscope", "sub"] run(args) # TODO: NOT called yet, need to find out how to make sure the plugin is available first @@ -165,5 +182,28 @@ class KrbInstance: extop_fd.close() #add an ACL to let the DS user read the master key - args = ["/usr/bin/setfacl", "-m", "u:"+self.ds_user+":r", "/var/kerberos/krb5kdc/.k5."+self.realm_name] + args = ["/usr/bin/setfacl", "-m", "u:"+self.ds_user+":r", "/var/kerberos/krb5kdc/.k5."+self.realm] run(args) + + def __create_sample_bind_zone(self): + bind_txt = template_file(SHARE_DIR + "bind.zone.db.template", self.sub_dict) + [bind_fd, bind_name] = tempfile.mkstemp(".db","sample.zone.") + os.write(bind_fd, bind_txt) + os.close(bind_fd) + print "Sample zone file for bind has been created in "+bind_name + + def __create_ds_keytab(self): + (kwrite, kread, kerr) = os.popen3("/usr/kerberos/sbin/kadmin.local") + kwrite.write("addprinc -randkey ldap/"+self.fqdn+"@"+self.realm+"\n") + kwrite.flush() + kwrite.write("ktadd -k /etc/fedora-ds/ds.keytab ldap/"+self.fqdn+"@"+self.realm+"\n") + kwrite.flush() + kwrite.close() + kread.close() + kerr.close() + + cfg_fd = open("/etc/sysconfig/fedora-ds", "a") + cfg_fd.write("export KRB5_KTNAME=/etc/fedora-ds/ds.keytab\n") + cfg_fd.close() + pent = pwd.getpwnam(self.ds_user) + os.chown("/etc/sysconfig/fedora-ds", pent.pw_uid, pent.pw_gid) From abartlet at samba.org Fri Jul 20 02:11:25 2007 From: abartlet at samba.org (Andrew Bartlett) Date: Fri, 20 Jul 2007 12:11:25 +1000 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469F978B.4030401@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> <469F978B.4030401@redhat.com> Message-ID: <1184897485.3715.5.camel@localhost.localdomain> On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote: > Karl MacMillan wrote: > > That solves our problem assuming that we can somehow handle the > > authentication through the web gui to the xmlrpc layer. We could: > > > > 1) remove the xmlrpc layer (either entirely or just for the web gui) > > > > 2) invent some way to pass who the user is and handle 'local' > > communication between the gui and xmlrpc layer. > > > > We've debated several times whether the xmlrpc layer is truly useful - I > > like it mainly because it gives a language neutral interface. However, > > since it is causing a signification amount of complexity (not just this > > - there is also the API design issues) I suggest we drop it for v1. We > > can simply use a common python library for the web and commandline > > interfaces. That should reduce our development time as well. > > > > Thoughts? > > > As devil's advocate I feel compelled to point out that an approach that > places the system logic into client libraries (rather than on the > server) runs the risk of much more resistance to change in the future, > since now that change has a greater and more far reaching impact: > clients get built, sold, and generally hang around being a nuisance. I was expecting that as part of 1) above, you would keep XML-RPC for the command line client, so that you maintain this benefit. That could then call the same backend functions as the web gui, and we still only have one kerberos-authenticated network hop. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From kmacmill at redhat.com Fri Jul 20 13:29:29 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 20 Jul 2007 09:29:29 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1184897485.3715.5.camel@localhost.localdomain> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> <469F978B.4030401@redhat.com> <1184897485.3715.5.camel@localhost.localdomain> Message-ID: <1184938169.15689.7.camel@localhost.localdomain> On Fri, 2007-07-20 at 12:11 +1000, Andrew Bartlett wrote: > On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote: > > Karl MacMillan wrote: > > > > That solves our problem assuming that we can somehow handle the > > > authentication through the web gui to the xmlrpc layer. We could: > > > > > > 1) remove the xmlrpc layer (either entirely or just for the web gui) > > > > > > 2) invent some way to pass who the user is and handle 'local' > > > communication between the gui and xmlrpc layer. > > > > > > We've debated several times whether the xmlrpc layer is truly useful - I > > > like it mainly because it gives a language neutral interface. However, > > > since it is causing a signification amount of complexity (not just this > > > - there is also the API design issues) I suggest we drop it for v1. We > > > can simply use a common python library for the web and commandline > > > interfaces. That should reduce our development time as well. > > > > > > Thoughts? > > > > > As devil's advocate I feel compelled to point out that an approach that > > places the system logic into client libraries (rather than on the > > server) runs the risk of much more resistance to change in the future, > > since now that change has a greater and more far reaching impact: > > clients get built, sold, and generally hang around being a nuisance. > > I was expecting that as part of 1) above, you would keep XML-RPC for the > command line client, so that you maintain this benefit. That could then > call the same backend functions as the web gui, and we still only have > one kerberos-authenticated network hop. > We can certainly do that and base it on the python library. It just becomes a good deal of extra work for less benefit. I think we just need to figure out whether we would rather shorten the development time or include the xml-rpc layer. Karl > Andrew Bartlett > From kwirth at redhat.com Fri Jul 20 17:57:30 2007 From: kwirth at redhat.com (Karl Wirth) Date: Fri, 20 Jul 2007 13:57:30 -0400 Subject: [Freeipa-devel] freeipa-interest Message-ID: <46A0F78A.3030807@redhat.com> We have created another mailing list for freeipa. This is for people who are interested in freeipa and want occasional updates on our progress and high level IPA discussion but don't want to participate in more detailed development discussions. Subscribe to https://www.redhat.com/mailman/listinfo/freeipa-interest Regards, Karl From rcritten at redhat.com Fri Jul 20 20:50:13 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Jul 2007 16:50:13 -0400 Subject: [Freeipa-devel] [PATCH] proof-of-concept of cli and xmlrpc Message-ID: <46A12005.2000700@redhat.com> Attached is a proof-of-concept patch of doing basic work over XML-RPC running on Apache. There are still a ton of hardcoded elements to this but it does basic add and find user. I tested this on a fresh F7 installation. I first installed from ipa-server and got the basic system up. That is still a little twitchy but can be made to work. Then I installed in ipa-web and started Apache. I was able to add a couple of users and search for them. A password is not set for them. To do this you can use kadmin.local. Of course to use kadmin.local you have to first set in /etc/krb5.conf: ldap_kadmind_dn = cn=Directory Manager Then set /var/kerberos/krb5kdc/ldappwd with the password for Directory Manager as selected when you installed freeipa. Note that if you stop and try to restart the krb5kdc service like this it will fail with an extremely cryptic error message. To start the service you have to use the uid=kdc DN. Anyway, once this is done you can do: kadmin.local: cpw And the additional elements and password will be set for the user. I was able to obtain and use a ticket. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.diff Type: text/x-patch Size: 44151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From ssorce at redhat.com Mon Jul 23 08:45:07 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 23 Jul 2007 04:45:07 -0400 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <469FA2F0.90201@redhat.com> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> <469F978B.4030401@redhat.com> <1184864674.26842.29.camel@localhost.localdomain> <469FA2F0.90201@redhat.com> Message-ID: <1185180307.3298.13.camel@hopeson> On Thu, 2007-07-19 at 10:44 -0700, Pete Rowley wrote: > Karl MacMillan wrote: > > On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote: > > > > > > In previous discussions I thought we had decided that it would be > > available if we were willing to assume the testing burden. > > > > > I don't recall that specifically for this but if we need it it needs to > be compiled in e.g. in RHDS 8.0 which almost certainly doesn't right > now, it isn't in a plugin, it is core. I remember this as well, and the deal was that we would test it, but no official support would be provided in 8.0, it would be provided only as part of IPA until deemed stable enough to be included officially in RHDS (maybe in 8.1 ?). > > Agreed on all 3 points - which is why I suggested it :) I think this is > > a short-term architectural decision not a long term one. > > > > > I am pointing out that it isn't so short term and as such we need to go > in with eyes wide open. I am sorry I couldn't chime in before. We need the krb auth in any case, but the forwardable ticket bit can indeed be skipped for v1 using the ldapi:// feature. But we _need_ the RPC layer, for many reasons. One reason is certainly the fact that we don't want to let people use too much ldap at this stage or that will mean our ability to change schemas and DIT structure will be critically restrained. And we absolutely need the flexibility to change them to grow in v2 and v3. Also (and this is important imo) we want to support multimaster setups, and we need a method for one server to talk to another when changes are made to configuration parameters not stored in ldap. Without an RPC layer this is going to quickly become a mess of custom developed assortment of mechanisms. The RPC layer is not just about the GUI, it is about controlling a server in many aspects, not only LDAP objects. So if Kerberos proxying/forwarding is the problem, let's just reduce the amount of work to address that problem and move on with our RPC stuff. But cutting RPC out of the picture is going to be more work then not doing it in the medium term imo. Simo. From ssorce at redhat.com Mon Jul 23 08:58:52 2007 From: ssorce at redhat.com (Simo Sorce) Date: Mon, 23 Jul 2007 04:58:52 -0400 Subject: [Freeipa-devel] User questions In-Reply-To: <469F6DDD.3090805@redhat.com> References: <469F6DDD.3090805@redhat.com> Message-ID: <1185181132.3298.26.camel@hopeson> On Thu, 2007-07-19 at 09:57 -0400, Rob Crittenden wrote: > A few questions about adding a user: > > 1. With our current objectclasses we are required to include cn and sn > (but gn is forbidden). In a GUI it is easy to simply ask for first and > last name and concatenate them to get cn (and probably use it for gecos > too). In a CLI it is a bit awkward to ask for first name. To be luseradd > compatible we could require 'gecos' and split that on the first space > but that is likely to cause problems. The SN problem is a though one (no wonder MS took the easy way and simply made it optional and not required). Splitting GECOS simply does not work. There are places where people do _not_ have Surnames, or places where it is common to have 2 names and 2 surnames, so you may not know or can't split on spaces. The idea we had was that we can use a templating mechanism that will put something like $SURNAME in SN and then based on the resolution mechanism chosen by the admin (or a custom plugin if they are brave) they will be able to tell directory how to fill in the field by substituting $SURNAME > 2. Someone is going to write a uid-generator, right? So I just need to > get "get_new_uid()" or something? The FDS should do it internally, the only problem I'd like to make sure we address is to avoid the risk of assigning conflicting IDs if 2 admins start creating users on 2 different servers. But this is, kin any case, server's magic the GUI does not care. > 3. What should the gid be set to by default? We are creating a group for > each user with the same username/uid? Here I'd like to propose a radical approach (which must be *optional* for compatibility reasons, but should be recommended IMO). The proposal is to, sort of, "unify" the UID and GID spaces, by effectively always allocating an UID and a GID. If what we have is a user then we effectively always create a user and a user's group with UID == GID, if it is a group then we just "eat" an UID leaving a hole in the UID space. This schema helps with windows integration where SIDs are monotonic and represent anything (users, groups, etc..) so that if we use this schema we can easily make a SID by simply attaching the ID to a domain SID. (the user's group == user UID is not a problem if managed correctly at the ACL level, more on this later if needed). Comments, esp from abartlet, welcome. Simo. From rmeggins at redhat.com Mon Jul 23 15:17:53 2007 From: rmeggins at redhat.com (Richard Megginson) Date: Mon, 23 Jul 2007 09:17:53 -0600 Subject: [Freeipa-devel] New version of Fedora DS released in Fedora Message-ID: <46A4C6A1.9030701@redhat.com> Fedora DS 1.1.0 alpha 4 was released in Fedora this weekend. This version gets rid of ds_newinst.pl and uses /usr/sbin/setup-ds.pl for new instance creation. setup-ds.pl allows you to * create an instance interactively - dialogs ask you questions and provide you with default answers * create an instance with no .inf file - you can provide the defaults on the command line e.g. setup-ds.pl slapd.ServerPort=389 * create an instance with a pre-hashed password for the directory manager - the command /usr/bin/pwdhash can be used to generate the password setup-ds.pl --help will give you some idea. NOTE: setup-ds.pl creates a log by default. If you do not want a log, use setup-ds.pl ... -l /dev/null ... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From prowley at redhat.com Mon Jul 23 16:47:36 2007 From: prowley at redhat.com (Pete Rowley) Date: Mon, 23 Jul 2007 09:47:36 -0700 Subject: [Freeipa-devel] another snag with kerberos In-Reply-To: <1185180307.3298.13.camel@hopeson> References: <469BDCE0.6040007@redhat.com> <1184673677.32455.0.camel@hopeson> <469CBDE7.1000203@redhat.com> <1184682821.15593.6.camel@finch.boston.redhat.com> <1184682933.3246.0.camel@localhost.localdomain> <469CD974.3070101@redhat.com> <1184810919.5094.112.camel@localhost.localdomain> <469EC8B2.5000603@redhat.com> <1184812570.5094.117.camel@localhost.localdomain> <1184850153.26842.17.camel@localhost.localdomain> <469F978B.4030401@redhat.com> <1184864674.26842.29.camel@localhost.localdomain> <469FA2F0.90201@redhat.com> <1185180307.3298.13.camel@hopeson> Message-ID: <46A4DBA8.1070301@redhat.com> Simo Sorce wrote: > On Thu, 2007-07-19 at 10:44 -0700, Pete Rowley wrote: > >> Karl MacMillan wrote: >> >>> On Thu, 2007-07-19 at 09:55 -0700, Pete Rowley wrote: >>> >>> >>> In previous discussions I thought we had decided that it would be >>> available if we were willing to assume the testing burden. >>> >>> >>> >> I don't recall that specifically for this but if we need it it needs to >> be compiled in e.g. in RHDS 8.0 which almost certainly doesn't right >> now, it isn't in a plugin, it is core. >> > > I remember this as well, and the deal was that we would test it, but no > official support would be provided in 8.0, it would be provided only as > part of IPA until deemed stable enough to be included officially in RHDS > (maybe in 8.1 ?). > > What you remember is support for chain on update being discussed, functionality that already exists in the server - there was no blanket agreement for any feature we might want. -- Pete -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3241 bytes Desc: S/MIME Cryptographic Signature URL: From rcritten at redhat.com Fri Jul 27 03:17:21 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Jul 2007 23:17:21 -0400 Subject: [Freeipa-devel] TurboGears mock-up Message-ID: <46A963C1.702@redhat.com> Attached is a simple TurboGears GUI mock-up that uses the same xmlrpc library as the basic command-line. Add user works, nothing else. And boy is it minimalistic. It does demonstrate a few things: - Retrieve a list of fields to request - Automatically configure validators for those fields for both requirements and for conforming to field type - Displays a semi-useful error message (user already exists, error in form, etc) There is a bug in the funcs.py I submitted earlier. In the userPassword field String should be string. All this means is that there is no validator for the password field in the GUI. I've implemented a bit more but it isn't in any shippable state (even for demo purposes). I had to refactor things a fair bit both to be more XML-RPC-like and to be more object-oriented. Should be ready in another couple of weeks. Need to work on authentication/authorization first. To install turbogears in F7 you just need to do: yum install TurboGears For now just run TurboGears as a separate web server via: ./start-ipagui.py Now hit http://ipaserver:8080/ The following packages were installed on my system: python-cheetah python-paste python-kid python-setuptools python-formencode python-turbokid python-paste-deploy python-paste-script python-turbocheetah python-json python-turbojson python-simplejson postgresql-libs python-psycopg2 python-decoratortools python-configobj python-cherrypy python-protocols python-ruledispatch python-sqlite2 python-sqlobject python-tgfastdata python-TestGears python-nose TurboGears rob -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-gui.tar.gz Type: application/x-gzip Size: 90324 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Fri Jul 27 17:41:14 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 27 Jul 2007 13:41:14 -0400 Subject: [Freeipa-devel] Repo layout changes Message-ID: <1185558074.3447.3.camel@localhost.localdomain> As I've been doing RPM spec files I realized the current repo layout didn't match how we wanted to distribute the software. I've reorganized it as follows: freeipa/ freeipa/ipa-server # all of the server components freeipa/ipa-server/ipa-install # server installer freeipa/ipa-server/ipa-slapi-plugins # DS slapi plugins freeipa/ipa-server/ipa-web # web gui and web services freeipa/ipa-admintools # commandline admin tools There will eventually be an ipa-client top-level for client config tools (that take care of pam and other config on clients). This matches the 3 RPMs that I intend to make: freeipa-server # all of the server components (installer, web, etc.) freeipa-admintools # commandline admin tools (usable off of the server) freeipa-client # client config tools I'll this in very shortly - sorry about any breakage this causes. Karl From rcritten at redhat.com Fri Jul 27 17:55:18 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Jul 2007 13:55:18 -0400 Subject: [Freeipa-devel] python gssapi interface and general status Message-ID: <46AA3186.1060901@redhat.com> I've decided to use PyKerberos for the GSSAPI interface needed by the ipa cli tools. Unfortunately it isn't packaged in Fedora (though Debian seems to have a package for it). There also doesn't seem to be much of a home for it other than: http://svn.macosforge.org/repository/collaboration/PyKerberos/ I pulled the trunk and was able to do HTTP-based GSSAPI authentication with few problems. So now I think I have all the pieces needed for authentication and basic authorization (using LDAP proxy auth with SSL client auth). I just need to try to tie all this together in a cohesive way. My brain is really, really full at the moment. Hopefully integrating this stuff will be straightforward. Just to map things out, it will look something like this: client -> GSSAPI with XML-RPC payload -> Apache/mod_auth_kerb -> XML-RPC server-> SSL client auth/LDAPS/proxy with $REMOTE_USER -> LDAP And at some point we'll insert SSL into the IPA client->server communication too. For the proxy auth I'll do a search for uid=$REMOTE_USER to get the full DN to proxy as. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kmccarth at redhat.com Fri Jul 27 18:18:48 2007 From: kmccarth at redhat.com (Kevin McCarthy) Date: Fri, 27 Jul 2007 11:18:48 -0700 Subject: [Freeipa-devel] Mercurial and committing Message-ID: <20070727181848.GA22708@kmccarth.sfbay.redhat.com> Hi All, First time mercurial user. I just finished the tutorial and scanned some of the FAQ's on their site. It looks like we do have a "central repository" that we can pull from. To commit changes I saw on the wiki that we send patches to this list. This is probably a dumb question, but is there a particular _person_ on the list who grabs patches, approves them, and notifies the list or submitter? I only see one email in the archives with [PATCH] in the subject, and no replies to that email. thanks for any illumination, -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2228 bytes Desc: not available URL: From kmacmill at redhat.com Fri Jul 27 19:10:58 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Fri, 27 Jul 2007 15:10:58 -0400 Subject: [Freeipa-devel] Mercurial and committing In-Reply-To: <20070727181848.GA22708@kmccarth.sfbay.redhat.com> References: <20070727181848.GA22708@kmccarth.sfbay.redhat.com> Message-ID: <1185563458.3447.9.camel@localhost.localdomain> On Fri, 2007-07-27 at 11:18 -0700, Kevin McCarthy wrote: > Hi All, > > First time mercurial user. I just finished the tutorial and scanned > some of the FAQ's on their site. It looks like we do have a "central > repository" that we can pull from. To commit changes I saw on the wiki > that we send patches to this list. > > This is probably a dumb question, but is there a particular _person_ on > the list who grabs patches, approves them, and notifies the list or > submitter? I only see one email in the archives with [PATCH] in the > subject, and no replies to that email. > Me, Simo, or Pete - one of us will pick up the patch and commit it or request changes. I've been trying to send emails when things get committed, but we should be more diligent about that. Karl From kmccarth at redhat.com Mon Jul 30 15:55:01 2007 From: kmccarth at redhat.com (Kevin McCarthy) Date: Mon, 30 Jul 2007 08:55:01 -0700 Subject: [Freeipa-devel] AJAX and section 508 compliance Message-ID: <20070730155456.GA3576@moon.usersys.redhat.com> Last week Bob (Lord) asked me to play around with some ajax'ish UI prototypes for user management. I have a demo running at http://moon.usersys.redhat.com:3000/users/ It's hitting against bart, so is a bit slow, but you can see some of the ideas. (The LDAP library I'm using is limiting results on the _client_ side, so try to type more than 3 characters for filtering - it's just a prototype). Someone (I think it was Mairin) mentioned there may be Section 508 issues we need to be concerned with. What is the teams view on ajax UI enhancements? Are we going to only support modern browers with javascript, use ajax but gracefully fall back, or use a compatible and accessible (but primitive) UI. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2228 bytes Desc: not available URL: From kmccarth at redhat.com Mon Jul 30 18:14:39 2007 From: kmccarth at redhat.com (Kevin McCarthy) Date: Mon, 30 Jul 2007 11:14:39 -0700 Subject: [Freeipa-devel] Turbogears Message-ID: <20070730181437.GC3576@moon.usersys.redhat.com> I've been playing with TurboGears a bit recently. I like some parts of it, but not others (I'm a python beginner, so that's part of it I guess). One thing that really bothers me is that TurboGears seems to crash/shutdown easily. If you type def foo() and forget the colon, then save your file, your server shuts down. This doesn't promote the "rapid-development" model these kind of frameworks espouse. Do any of you know a fix for this? Smaller things I find weird is that SQLObjects save on contruction, which doesn't lend itself to temporary model objects. And "widgets" invoke bad memories of JSP tags. I'd be interested to hear some of the good experiences/high points for this framework from others. I'm trying not to judge too much as I've only done the tutorial. thanks, -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2228 bytes Desc: not available URL: From rcritten at redhat.com Mon Jul 30 18:40:01 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jul 2007 14:40:01 -0400 Subject: [Freeipa-devel] Turbogears In-Reply-To: <20070730181437.GC3576@moon.usersys.redhat.com> References: <20070730181437.GC3576@moon.usersys.redhat.com> Message-ID: <46AE3081.6040904@redhat.com> Kevin McCarthy wrote: > I've been playing with TurboGears a bit recently. I like some parts of > it, but not others (I'm a python beginner, so that's part of it I > guess). > > One thing that really bothers me is that TurboGears seems to > crash/shutdown easily. If you type def foo() and forget the colon, then > save your file, your server shuts down. This doesn't promote the > "rapid-development" model these kind of frameworks espouse. Do any of > you know a fix for this? It crashes because it can't reload the updated python. I find it annoying too but have just gotten used to it (and better at python syntax). > Smaller things I find weird is that SQLObjects save on contruction, > which doesn't lend itself to temporary model objects. And "widgets" > invoke bad memories of JSP tags. We can't use SQLObjects can we? We don't have a SQL database. > I'd be interested to hear some of the good experiences/high points for > this framework from others. I'm trying not to judge too much as I've > only done the tutorial. > > thanks, One of the main factors in choose it was the ability to easy forge ahead using generic objects (dicts, lists and such) instead of SQL objects. And since python was chosen as the language for the XML-RPC server having one language across things is nice. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kmccarth at redhat.com Mon Jul 30 18:53:39 2007 From: kmccarth at redhat.com (Kevin McCarthy) Date: Mon, 30 Jul 2007 11:53:39 -0700 Subject: [Freeipa-devel] Turbogears In-Reply-To: <46AE3081.6040904@redhat.com> References: <20070730181437.GC3576@moon.usersys.redhat.com> <46AE3081.6040904@redhat.com> Message-ID: <20070730185338.GE3576@moon.usersys.redhat.com> Rob Crittenden wrote: > It crashes because it can't reload the updated python. I find it annoying > too but have just gotten used to it (and better at python syntax). Alighty, I'll have to be more careful too then. It makes me a bit scared of production stability though. I'd rather one controller serve up 500 Server Errors than the entire server crash. Hopefully it only behaves this way for Python syntax errors, and not for other things that are harder to test. >> Smaller things I find weird is that SQLObjects save on contruction, >> which doesn't lend itself to temporary model objects. And "widgets" >> invoke bad memories of JSP tags. > > We can't use SQLObjects can we? We don't have a SQL database. Yes, thank goodness. I just found the design odd, is all. > One of the main factors in choose it was the ability to easy forge ahead > using generic objects (dicts, lists and such) instead of SQL objects. And > since python was chosen as the language for the XML-RPC server having one > language across things is nice. I agree. The less languages/technologies involved the better. How have you found the 'kid' and user interface tools so far? The tutorial doesn't cover much ground there. -Kevin -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2228 bytes Desc: not available URL: From rcritten at redhat.com Mon Jul 30 18:59:51 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Jul 2007 14:59:51 -0400 Subject: [Freeipa-devel] Turbogears In-Reply-To: <20070730185338.GE3576@moon.usersys.redhat.com> References: <20070730181437.GC3576@moon.usersys.redhat.com> <46AE3081.6040904@redhat.com> <20070730185338.GE3576@moon.usersys.redhat.com> Message-ID: <46AE3527.7000104@redhat.com> Kevin McCarthy wrote: > Rob Crittenden wrote: >> It crashes because it can't reload the updated python. I find it annoying >> too but have just gotten used to it (and better at python syntax). > > Alighty, I'll have to be more careful too then. It makes me a bit > scared of production stability though. I'd rather one controller serve > up 500 Server Errors than the entire server crash. Hopefully it only > behaves this way for Python syntax errors, and not for other things that > are harder to test. Yes, some errors cause it to completely wig out and crash, others are just displayed. > >>> Smaller things I find weird is that SQLObjects save on contruction, >>> which doesn't lend itself to temporary model objects. And "widgets" >>> invoke bad memories of JSP tags. >> We can't use SQLObjects can we? We don't have a SQL database. > > Yes, thank goodness. I just found the design odd, is all. > > >> One of the main factors in choose it was the ability to easy forge ahead >> using generic objects (dicts, lists and such) instead of SQL objects. And >> since python was chosen as the language for the XML-RPC server having one >> language across things is nice. > > I agree. The less languages/technologies involved the better. > > How have you found the 'kid' and user interface tools so far? The > tutorial doesn't cover much ground there. I just used vi myself. At least some of the tools only work when you use SQLObjects (they don't even work with the alternate object SQLAlchemy). rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Mon Jul 30 21:48:45 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Mon, 30 Jul 2007 17:48:45 -0400 Subject: [Freeipa-devel] Commits Message-ID: <1185832125.3247.1.camel@localhost.localdomain> I committed the attached patch to the repo (rebased version of the patch Rob sent for admin tools) and initial support for creating RPMs of freeipa. Karl -------------- next part -------------- A non-text attachment was scrubbed... Name: xmlrpc.diff Type: text/x-patch Size: 45253 bytes Desc: not available URL: From rcritten at redhat.com Tue Jul 31 16:15:50 2007 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 31 Jul 2007 12:15:50 -0400 Subject: [Freeipa-devel] PyKerberos srpm Message-ID: <46AF6036.1080706@redhat.com> Attached is a source RPM for Apple's PyKerberos package. They use it for their calendar server, I plan to use it for command-line GSSAPI. There doesn't seem to be an official release of PyKerberos yet so I just pulled the most recent SVN release and used that. I did e-mail the author to see if he is planning on doing a separate release. I just stuck the SVN version into the RPM versioning for now. rob -------------- next part -------------- A non-text attachment was scrubbed... Name: PyKerberos-0.1735-1.fc7.src.rpm Type: application/x-redhat-package-manager Size: 43241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From bob.lord at redhat.com Tue Jul 31 18:13:40 2007 From: bob.lord at redhat.com (Bob Lord) Date: Tue, 31 Jul 2007 11:13:40 -0700 Subject: [Freeipa-devel] AJAX and section 508 compliance In-Reply-To: <20070730155456.GA3576@moon.usersys.redhat.com> References: <20070730155456.GA3576@moon.usersys.redhat.com> Message-ID: <46AF7BD4.1010005@redhat.com> Kevin McCarthy wrote: > Last week Bob (Lord) asked me to play around with some ajax'ish UI > prototypes for user management. I have a demo running at > http://moon.usersys.redhat.com:3000/users/ > It's hitting against bart, so is a bit slow, but you can see some of the > ideas. (The LDAP library I'm using is limiting results on the _client_ > side, so try to type more than 3 characters for filtering - it's just a > prototype). > > Someone (I think it was Mairin) mentioned there may be Section 508 > issues we need to be concerned with. What is the teams view on > ajax UI enhancements? Are we going to only support modern browers with > javascript, use ajax but gracefully fall back, or use a compatible and > accessible (but primitive) UI. > Karl Wirth: There is a bit of a tradeoff between Section 508 compliance and the AJAX UI/UE we're building. Adding Section 508 compliance to the mix will add a good deal of time to the schedule which at this point we can't afford. I propose that we *not* aim for 508 compliance in IPA 1.0. If you agree, can you update the PRD to reflect that decision? Regards, -Bob -------------- next part -------------- A non-text attachment was scrubbed... Name: bob.lord.vcf Type: text/x-vcard Size: 166 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4038 bytes Desc: S/MIME Cryptographic Signature URL: From kmacmill at redhat.com Tue Jul 31 18:45:31 2007 From: kmacmill at redhat.com (Karl MacMillan) Date: Tue, 31 Jul 2007 14:45:31 -0400 Subject: [Freeipa-devel] AJAX and section 508 compliance In-Reply-To: <46AF7BD4.1010005@redhat.com> References: <20070730155456.GA3576@moon.usersys.redhat.com> <46AF7BD4.1010005@redhat.com> Message-ID: <1185907531.14214.8.camel@localhost.localdomain> On Tue, 2007-07-31 at 11:13 -0700, Bob Lord wrote: > Kevin McCarthy wrote: > > Last week Bob (Lord) asked me to play around with some ajax'ish UI > > prototypes for user management. I have a demo running at > > http://moon.usersys.redhat.com:3000/users/ > > It's hitting against bart, so is a bit slow, but you can see some of the > > ideas. (The LDAP library I'm using is limiting results on the _client_ > > side, so try to type more than 3 characters for filtering - it's just a > > prototype). > > > > Someone (I think it was Mairin) mentioned there may be Section 508 > > issues we need to be concerned with. What is the teams view on > > ajax UI enhancements? Are we going to only support modern browers with > > javascript, use ajax but gracefully fall back, or use a compatible and > > accessible (but primitive) UI. > > > > Karl Wirth: > > There is a bit of a tradeoff between Section 508 compliance and the AJAX > UI/UE we're building. Adding Section 508 compliance to the mix will add > a good deal of time to the schedule which at this point we can't afford. > > I propose that we *not* aim for 508 compliance in IPA 1.0. If you > agree, can you update the PRD to reflect that decision? > I think that having a responsive UI would be great (and Ajax is about the only way to get this). However, I think that it will add a significant amount of complication over a more basic approach. I'd rather have a basic, static web UI in less amount of time. That will give us our fallback, including something that is likely close to 508 compliant, and we can add dynamic elements in the future. Karl