If it was me, I think I'd just add P_ID and O_ID to Employees. The same Position might be filled by multiple employees, and there might be multiple Employees at a given Office, but it's unlikely (without using Cloning technology) that the same Employee would need to be replicated multiple times - thus, just add P_ID and O_ID to Employee and I think you're good to go. Of course, you'll need foreign key constraints from Employee to Position (P_ID) and Office (O_ID).
EDIT: After some thought, and recalling that I've had jobs where I filled multiple positions (although at the same location), I suppose it's conceivable that a single person might have fill multiple positions which might be at different locations.
If you're really set on having a junction table between Employees, Positions, and Offices - OK, create a table called EmployeePositionOffice (or something like that) which contains the three columns E_ID, P_ID, and O_ID. The primary key should be (E_ID, P_ID, O_ID), and each field should be foreign-keyed to the related base table.
EDIT:
Not sure about the SQL Server syntax, but in Oracle the first would be something like:
ALTER TABLE EMPLOYEES
ADD (P_ID NUMBER REFERENCES POSITIONS(P_ID),
O_ID NUMBER REFERENCES OFFICES(O_ID));
while the second would be something like
CREATE TABLE EMPLOYEES_POSISTIONS_OFFICES
(E_ID NUMBER REFERENCES EMPLOYEES(E_ID),
P_ID NUMBER REFERENCES POSITIONS(P_ID),
O_ID NUMBER REFERENCES OFFICES(O_ID),
PRIMARY KEY (E_ID, P_ID, O_ID));
Share and enjoy.