[Freeipa-devel] [PATCH] a step closer to the final directory layout

[Rob Crittenden]

Simo Sorce wrote:
> On Thu, 2007-08-30 at 08:54 -0400, Rob Crittenden wrote:
> 
>>> +dn: uid=admin,cn=users,cn=accounts,$SUFFIX
>>>   
>> If you are going to change the name of this account you need to update 
>> the client certificate that is generated during install time as well.
> 
> uhmm not sure what you mean here, admin is a new user, none existed
> before. If you refer to webservice, it retain it's name, it is just
> moved in another place and I couldn't find anywhere the full dn, is this
> something I missed, can you point me at the line in the setup scripts?

-dn: uid=webservice,ou=special,$SUFFIX
+dn: cn=sysaccounts,cn=etc,$SUFFIX
  changetype: add
+objectClass: nsContainer
+objectClass: top
+cn: sysaccounts
+
+dn: uid=webservice,cn=sysaccounts,cn=etc,$SUFFIX
+changetype: add
+objectClass: top
+objectClass: account
  uid: webservice
-objectClass: account

This change. You've changed the DN. It may still work, I think I just 
use the uid in certmap.conf but it needs testing.

> 
>>> +gidNumber: 1001
>>> +uniqueMember: uid=admin,cn=sysaccounts,cn=etc,$SUFFIX
>>>   
>> I think we are asking for trouble arbitrarily picking gid and uid 
>> numbers in the 1000's. It is going to make migration difficult for 
>> existing infrastructures. And I don't buy the "it is for new installs 
>> only." How many large organizations are going to start from scratch?
> 
> I agree with the principle, but I want QA and demos to work out of the
> box on a clean install. In the end no matter what UID we choose it may
> always clash with custom assigned IDs on existing production systems. I
> just want to set a recommendation on what to use here, if that is not
> ok, for the specific migration strategy adopted on the specific site
> then the admins of that site will change the IDs accordingly.
> 

But what will happen is that unless we specifically put a line in the 
sand now on migration we'll all probably forget about this until some 
problem is found. It seems to me that this is one of the core issues we 
need to solve and merely choosing a number at random punts the problem 
down the road for us to run into again.

>>>  aci: (targetattr!="userPassword || krbPrincipalKey ||sambaLMPassword || sambaNTPassword")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
>> krbPrincipalName is also required so we can resolve a principal into a 
>> dn for proxy binding.
> 
> But if I am not mistaken webservice is authenticated not anonymous so it
> should be able to read all, or is there something I am missing ?
> This ACI line actually just forbid reading the attributes where we store
> passwords.

Yes, I think you're right.
> 
>>> +dn: cn=justname,cn=mapping,cn=sasl,cn=config
>>>   
>> Should this really be justuid?
> 
> Pete suggested name only, and that's ok, "uid" is not as this is true
> for any principal name independently of how it is created (the principal
> name is not necessarily always identical to the uid).

ok

> 
>>> diff -r 7aba398c4d98 -r ded52fae8158 ipa-server/ipa-install/test/test-users-template.ldif
>>> --- a/ipa-server/ipa-install/test/test-users-template.ldif	Tue Aug 28 10:46:03 2007 -0400
>>> +++ b/ipa-server/ipa-install/test/test-users-template.ldif	Wed Aug 29 18:07:05 2007 -0400
>>> @@ -1,30 +1,22 @@
>>>  # test, users, default, $REALM
>>> -dn: uid=test,ou=users,ou=default,$SUFFIX
>>> +dn: uid=test,cn=users,cn=accounts,$SUFFIX
>>>  changetype: add
>>> -uidNumber: 1001
>>> +uidNumber: 1003
>>>  uid: test
>>>  gecos: test
>>>  homeDirectory: /home/test
>>>  loginShell: /bin/bash
>>> -shadowMin: 0
>>> -shadowWarning: 7
>>> -shadowMax: 99999
>>> -shadowExpire: -1
>>> -shadowInactive: -1
>>> -shadowLastChange: 13655
>>> -shadowFlag: -1
>> Should the shadow* stuff be removed from add_user in funcs.py?
> 
> As we don't use shadow passords and as the KDC can't read shadow attributes I think we should remove them and ban shadowAccount altogether as these attributes will not be properly changed on password changes and other administrative tasks.

I'll take that as a "yes" :-)

> 
>> Have you stood up an IPA server and tested these changes?
> 
> I tested some of these changes in my test machine that almost died in an
> update (rawhide). So actually no, I will integrate yours and Pete's
> corrections and test a full install from scratch and then submit a
> corrective additional patch.
> 
> Simo.
> 

-------------- 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: <http://listman.redhat.com/archives/freeipa-devel/attachments/20070830/d3cb21be/attachment.bin>