[Fusionforge-general] PHP Hacks: Offsets to avoid company UID's/GID's

Curt Mills hacker at fluke.com
Fri Aug 14 23:16:31 CEST 2009


On Wed, 12 Aug 2009, Christian Bayle wrote:

> Maybe just explain what you have access to, AD with SFU or not, possibility 
> to have your server registered in AD or not (How you register your server in 
> kerberos db),  How you get the UID/GID,
> your infrastructure description, and  we'll try to find the best way to  do 
> things  and describe it as
> a test case in some usefull wiki page on fusionforge wiki

User authentication is via Kerberos.

Authorization is via AD for Windows boxes, LDAP for Linux boxes.  AD
does _not_ have SFU installed but has a similar sort of thing.  That
"similar" sort of thing stores similar types of info but in
different places.  AD is out of the question for my uses based on a
discussion I just had with I.T.

The LDAP master server gets updates from AD multiple times a day,
so AD is the top authority, LDAP is secondary.  LDAP lags AD by XX
hours.

The Linux server in question is running LDAP w/Kerberos.  Company
logins work fine on that machine and give users auto-mounted home
directories.

FusionForge is not using CVS but only SVN, web pages per project are
not being used.  Most of the rest of FusionForge is enabled (and was
working a few weeks ago with custom PHP hacks in the form of
GForge).  I'm using the server for multiple purposes (not just
FusionForge).

For the last 2.5 years I was using the "UNIX" plugin and writing
user & group information to /etc/* via cron.  I had done custom PHP
hacks to offset the UID's/GID's by 45,000 to avoid the
company-assigned ones.  I cannot create accounts except locally.
The whole "code is smart enough to avoid already-assigned
UID's/GID's" doesn't work for me either 'cuz I.T. can assign any of
those later.  I need to avoid their whole number domain if there
might be a conflict.

Because I'm not using project home pages or CVS, I _think_ I can get
by with disabling the crontab which writes to /etc/[passwd | shadow
| group] and have done so.  Again I _think_ I can just have the
accounts cached in Postgres and call it good (because of no project
web pages and no CVS needed).

What I'd like is to use the UID's/GID's from LDAP and authenticate
via Kerberos so that company logins would work in FusionForge.
Future upgrades to FusionForge wouldn't require (as many?) custom
PHP hacks.  I'd also like project UID's/GID's to not interfere with
the company assigned ones, perhaps a new global config option for an
offset in /etc/gforge?

So...   We authenticate the user via Kerberos, then pass user/pass
to LDAP using simple AUTH to get UID/GID/Netgroups/etc.  Here's the
infrastructure diagram:

AD -> LDSU -> LDAP database -> Master LDAP server -> Slave LDAP
servers.

I can query the slave LDAP servers and use Kerberos.  I cannot
create user/group/project accounts in AD or LDAP.  I have full
control over the FusionForge server and Postgres.

Anything else we'd need to know?  How do we get started!

-- 
Curt Mills, WE7U                             hacker at fluke dot com
Senior Methods Engineer/SysAdmin
   "Lotto:  A tax on people who are bad at math."     -- unknown
"Windows:  Microsoft's tax on computer illiterates." -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"

Please be advised that this email may contain confidential information.
 If you are not the intended recipient, please do not read, copy or
re-transmit this email.  If you have received this email in error,
please notify us by email by replying to the sender and by telephone
(call us collect at +1 202-828-0850) and delete this message and any
attachments.  Thank you in advance for your cooperation and assistance.

In addition, Danaher and its subsidiaries disclaim that the content of
this email constitutes an offer to enter into, or the acceptance of, 
any
contract or agreement or any amendment thereto; provided that the
foregoing disclaimer does not invalidate the binding effect of any
digital or other electronic reproduction of a manual signature that is
included in any attachment to this email.




More information about the Fusionforge-general mailing list