"Joe Butler" writes:

> How do I force a Linux installation to not re-used UIDs when creating new
> user accounts?
>
> So, if an old user is deleted from the system, not simply disabled, I don't
> want Linux assigning the old UID to the next user that is created.
>
> Where is the settting that will enable that?
>
> Some info for the record, that I have not found via any google searches for
> 'cannot join domain' [after restore] [SME Server].
>
> I need this to be a global setting and it is not going to work if I'm
> advised, "don't delete users, just disable them", since the server's manager
> interface will enable someone to delete users quite easily.

I don't know what this "server manager interface" is.

Most of the GUIs I've seen have an expert mode that will let you pick
a specific UID but I don't think you want to do that.

If you don't want to reuse UIDs, you have to retain a record of the used
UIDs somewhere. The simplest solution would be some scheme that involved
disabling UIDs instead of deleting them.

If you don't like that you can modify the "server manager interface"
to suit your needs.

Dan Espen wrote:
> "Joe Butler" writes:
>
>> How do I force a Linux installation to not re-used UIDs when creating new
>> user accounts?
>>
>> So, if an old user is deleted from the system, not simply disabled, I don't
>> want Linux assigning the old UID to the next user that is created.
>>
>> Where is the settting that will enable that?
>>
>> Some info for the record, that I have not found via any google searches for
>> 'cannot join domain' [after restore] [SME Server].
>>
>> I need this to be a global setting and it is not going to work if I'm
>> advised, "don't delete users, just disable them", since the server's manager
>> interface will enable someone to delete users quite easily.
>
> I don't know what this "server manager interface" is.
>
> Most of the GUIs I've seen have an expert mode that will let you pick
> a specific UID but I don't think you want to do that.
>
> If you don't want to reuse UIDs, you have to retain a record of the used
> UIDs somewhere. The simplest solution would be some scheme that involved
> disabling UIDs instead of deleting them.
>
> If you don't like that you can modify the "server manager interface"
> to suit your needs.

With the Red Hat distributions, if you use the gui program to add and remove
users, it starts new users at 500 and works up from there. I do not know
what happens if you remove the highest one, but if you remove any other, it
is not reused.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 22:20:01 up 3 days, 2:16, 0 users, load average: 4.10, 4.13, 4.13

Thanks for the responses. The problem is solved now, so a workaround (for
no reuse of UID) is not necessary.

Namely:
SME Server 6.0
Workstation cannot re-join the domain after restoring SME Server using
backup2ws (backup to workstation).

The reason this is not possible is that the unix password file restored to
the new server, does not contain any of the 'usernames' of the machines that
were previously joined to the domain server. Copying the orignal password
files direct from the original server hdd to the new installation rectified
the problem.

"The user name could not be found" refers not to the admin user and pass
entered when attempting to join a domain with a fresh machine, but to the
machine name that one attempts to join to the domain. Due to the sync
issue, the machine's generated user/pass combination are not correctly
entered into both password files which means it cannot be found at some
point during the joining to the domain.

"Joe Butler" wrote in message
news:46b62858$0$24759$da0feed9@news.zen.co.uk...
> How do I force a Linux installation to not re-used UIDs when creating new
> user accounts?
>
> So, if an old user is deleted from the system, not simply disabled, I
> don't want Linux assigning the old UID to the next user that is created.
>
> Where is the settting that will enable that?
>
> Some info for the record, that I have not found via any google searches
> for 'cannot join domain' [after restore] [SME Server].
>
> I need this to be a global setting and it is not going to work if I'm
> advised, "don't delete users, just disable them", since the server's
> manager interface will enable someone to delete users quite easily.
>
> The reason is that I have a syncronisation issue between the Samba
> password file and the Unix/Linux password file on my SME Server
> installation after a restore operation to new hardware. Users/worksations
> are being assigned UIDs based only on the content of the Unix password
> file, so when they are appended to the Samba password file, there are UID
> collisions. The main effect of this is that it is impossible to join a
> new machine to the samba 'domain' unless some dummy users are added into
> the Unix password file with:
>
> useradd dummy1
> usermod -L dummy1
>
> Adding as many dummyN users as necessary to force the next UID alloacated
> by the server manager interface to have a UID that is not already used for
> another user in the Samba password file. Namely the workstation that
> needs to be added to the domain. If the UID collides with an existing UID
> Windows reports, "The user name could not be found." and the machine is
> not joined to the domain. When the dummy users are added, joining the
> domain works.
>
>
>
>

In news:46b62858$0$24759$da0feed9@news.zen.co.uk,
Joe Butler wrote:

> How do I force a Linux installation to not re-used UIDs when creating
> new user accounts?
....
> I need this to be a global setting and it is not going to work if I'm
> advised, "don't delete users, just disable them", since the server's
> manager interface will enable someone to delete users quite easily.

If "someone" can disrupt the security of your system so readily, then the
entire security concept of "the server's manager interface" needs to be
discarded and replaced.

I did wonder about that too. I'm thinking of changing the root password
from 'root' to something more secure like r00t and installing a firewall
between the server and the Internet because I think we are getting exploited
by black hat phreakers.

"ynotssor" wrote in message
news:5hrfqlF3kvaguU1@mid.individual.net...
> In news:46b62858$0$24759$da0feed9@news.zen.co.uk,
> Joe Butler wrote:
>
>> How do I force a Linux installation to not re-used UIDs when creating
>> new user accounts?
> ...
>> I need this to be a global setting and it is not going to work if I'm
>> advised, "don't delete users, just disable them", since the server's
>> manager interface will enable someone to delete users quite easily.
>
> If "someone" can disrupt the security of your system so readily, then the
> entire security concept of "the server's manager interface" needs to be
> discarded and replaced.
>

On 2007-08-07, Joe Butler wrote:
> I did wonder about that too. I'm thinking of changing the root password
> from 'root' to something more secure like r00t and installing a firewall
> between the server and the Internet because I think we are getting exploited
> by black hat phreakers.

Please say you are not serious about the password. If you
are serious, please get some major professional help.

--
Robert Riches
spamtrap42@verizon.net
(Yes, that is one of my email addresses.)

In news:slrnfbh5sm.pvc.rob@one.localnet,
Robert M. Riches Jr. wrote:

>> I did wonder about that too. I'm thinking of changing the root
>> password from 'root' to something more secure like r00t and
>> installing a firewall between the server and the Internet because I
>> think we are getting exploited by black hat phreakers.
>
> Please say you are not serious about the password. If you
> are serious, please get some major professional help.

He just identified himself as a troll.

On 7 Aug, 17:17, "ynotssor" wrote:
> Innews:slrnfbh5sm.pvc.rob@one.localnet,
> Robert M. Riches Jr. wrote:
>
> >> I did wonder about that too. I'm thinking of changing the root
> >> password from 'root' to something more secure like r00t and
> >> installing a firewall between the server and the Internet because I
> >> think we are getting exploited by black hat phreakers.
>
> > Please say you are not serious about the password. If you
> > are serious, please get some major professional help.
>
> He just identified himself as a troll.

No, as someone who mistyped. He meant to say "username". I've seen
this approach used to allow root access via a separate account name
and password. Unfortunately, a bunch of poorly written shell scripts
do a test to see if the current username is "root" rather than
checking that the current UID is 0, and break as the system randomly
reponds that the username is root, r00t, shiver-my-access, or whatever
you set the spare usernames to.